November 30, 2020
Resource Isolation Policy prevents external websites from requesting your resources. Blocking such traffic mitigates common web vulnerabilities such as CSRF, XSSI, or XS-Leaks. The policy can be enabled for applications whose endpoints are not intended to be loaded in a cross-site context and will allow resource requests coming from your application as well as direct navigations.
Implementation with Fetch Metadata # The below snippet showcases an example implemention of the Resource Isolation Policy with the use of Fetch Metadata headers:
...
November 30, 2020
Framing Isolation Policy is a stricter version of Framing Protections where the request gets blocked at the application level rather than by the browser. This is designed to protect against various attacks (e.g. XSSI, CSRF, XS-Leaks) by blocking framing requests to endpoints that are not intended to be framable.
It can be combined with Resource Isolation Policy to effectively tighten the attack surface within cross-site information leaks.
tip
Instead of rejecting all non-framable endpoints, the user could be prompted to confirm the action, e.
...
November 30, 2020
Navigation Isolation Policy is a server-side protection mechanism intended to mitigate CSRF, clickjacking, reflected XSS, and XS-Leaks that make use of cross-site window contexts. This is a strict policy and has the potential to break an application since it blocks all cross-site navigations, including navigations through hyperlinks.
tip
Instead of rejecting all cross-site interactions, the user could be prompted to confirm the action, e.g. Confirm that you visited this page from a trusted origin, to mitigate the risk of attacks in the background, and, at the same time, help prevent unintended breakages of an application.
...
November 30, 2020
Strict Isolation Policy is intended to protect against all cross-site interactions (including navigations to the application through hyperlinks). This is a very strict policy that has the potential to prevent applications from functioning properly.
tip
Instead of rejecting all cross-site interactions, the user could be prompted to confirm the action, e.g. Confirm that you visited this page from a trusted origin, to mitigate the risk of attacks in the background, and, at the same time, help prevent unintended breakages of an application.
...
November 30, 2020
Fetch Metadata Request Headers are sent by browsers with HTTPS requests. These headers provide context on how a request was initiated so that applications are able to make more informed decisions on how to respond to them. This allows servers to behave differently when they detect potential attacks (e.g. unexpected cross-origin requests)[^1]. This can be very effective against cross-origin attacks like XSSI, XS-Leaks, Clickjacking, and CSRF if a strict policy is deployed on the server.
...
October 16, 2020
There are a number of different approaches applications can use to defend against cache probing-based XS-Leaks. These approaches are explained in the following sections.
Cache Protection via Cache-Control Headers # If it is acceptable to disable caching, doing so provides a strong defense against cache probing attacks. Disabling caching means that every time someone loads a resource, the resource has to be fetched again. To disable caching, set a Cache-Control: no-store header on every single response that you wish to protect.
...
October 1, 2020
Cross-Origin Read Blocking (CORB) is a security mechanism that prevents attackers from loading certain cross-origin resources 1. This protection was created to defend against speculative side-channel attacks such as Spectre that allow attackers to read the memory of the process that both cross-site pages (e.g. attacker.com and sensitive.com) were embedded into. CORB aims to prevent attackers from loading certain sensitive cross-origin resources into an attacker-controlled process. For example, if an attacker tries to load cross-origin HTML, XML, or JSON into an img tag, CORB prevents this from happening.
...
October 1, 2020
Getting access to a website’s window object is a common prerequisite for different XS-Leak techniques. Framing Protections can ensure that an attacker cannot use iframes to access the window object, but this does not stop an attacker from accessing the window object from an opened window through window.open(url) or window.opener references.
Exploiting XS-Leaks with window.open is generally seen as the least appealing option for an attacker because the user can see it happen in the open browser window.
...
October 1, 2020
Cross-Origin Resource Policy (CORP) is a web platform security feature that allows websites to prevent certain resources from being loaded by other origins. This protection complements CORB since it is an opt-in defense, whereas CORB blocks some cross-origin reads by default. CORP is designed to protect against both speculative execution attacks and XS-Leaks by allowing developers to ensure that sensitive resources cannot end up in attacker-controlled processes. Unlike CORB, this protection is enforced in the browser only if an application opts in to the protection.
...
October 1, 2020
A considerable number of XS-Leaks rely on some of the properties of iframes. If an attacker is unable to embed the contents of a page as an iframe, frame, embed or object, then the attack may no longer be possible. To mitigate XS-Leaks which rely on these objects, pages can forbid or select which origins can embed them. Doing so is possible by using the X-Frame-Options header or the CSP frame-ancestors directive.
...