diff --git a/content/docs/defenses/browser-intrinsic/corb.md b/content/docs/defenses/browser-intrinsic/corb.md index 6bfd372b4..07771f1a3 100644 --- a/content/docs/defenses/browser-intrinsic/corb.md +++ b/content/docs/defenses/browser-intrinsic/corb.md @@ -6,4 +6,26 @@ category = "defenses" menu = "main" +++ -TODO \ No newline at end of file + +## Explanation + +Cross-Origin Read Blocking (CORB) is a browser defense mechanism that prevents attackers from loading certain cross-origin resources in unlikely scenarios [^1]. This protection was created to prevent speculative side-channel attacks such as Spectre which allow attackers to read the memory of their own process. CORB aims to prevent attackers from loading cross-origin contents which might contain sensitive information into an attacker-controlled process. For instance, if an attacker tries to load an HTML, XML, or JSON as an `img` or `script` tag, CORB will prevent this from happening. + +To classify resource types CORB uses the `Content-Type` header if `nosniff` is set. In case the page does not serve a `nosniff` header CORB will, based on heuristics, check if the resource is worth protecting by looking at the beginning of the response body. + +{{< hint info >}} +Chrome is the only browser with CORB deployed. +{{< /hint >}} + +{{< hint info >}} +[Cross-Origin Resource Policy (CORP)]({{< ref "../opt-in/corp.md" >}}) is an opt-in protection which enforces and extends CORB. +{{< /hint >}} + + +## Considerations + +{{< hint warning >}} +CORB introduced a [new XS-Leak](https://TODO) since attackers are able to observe whether a request was blocked or allowed by CORB. This leads to information leaks when CORB blocks certain requests depending on user information the attacker is after. However, the introduced XS-Leak has a lower impact than a Spectre exploitation of the CORB-protected resources. +{{< /hint >}} + +[^1]: Cross-Origin Read Blocking for Web Developers, [link](https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md) diff --git a/content/docs/defenses/browser-intrinsic/double-keyd-cache.md b/content/docs/defenses/browser-intrinsic/double-keyd-cache.md deleted file mode 100644 index a29e80106..000000000 --- a/content/docs/defenses/browser-intrinsic/double-keyd-cache.md +++ /dev/null @@ -1,9 +0,0 @@ -+++ -title = "Double Keyed Cache" -description = "" -date = "2020-07-21" -category = "defenses" -menu = "main" -+++ - -TODO \ No newline at end of file diff --git a/content/docs/defenses/browser-intrinsic/partitioned-cache.md b/content/docs/defenses/browser-intrinsic/partitioned-cache.md new file mode 100644 index 000000000..c3346b33e --- /dev/null +++ b/content/docs/defenses/browser-intrinsic/partitioned-cache.md @@ -0,0 +1,64 @@ ++++ +title = "Partitioned HTTP Cache" +description = "" +date = "2020-07-21" +category = "defenses" +menu = "main" ++++ + +## Explanation + +[Cache probing attacks](https://TODO) have been present on the web for a long time mainly because browsers HTTP cache is shared across all the websites visited by a user, allowing attackers to interact with it and infer private information from other origins. + + + +Considering Opt-in solutions, applications can use the [`Vary` Header combined with `Fetch-Metadata`](https://TODO) to prevent cross-origin fetches to be affected by the site cache or use [some workarounds]({{< ref "../design-protections/subresource-protections.md" >}}) to protect resources, which come with downsides. Browsers, however, have been planning a defense mechanism to segregate the cached resources per origin/site, making it impossible for attackers pages to interact with cached contents of different origins[^1] [^2] [^3]. Specifically, browsers tested caching with finer-grained keys such as the tuple <`top-frame origin`, URL> or even triples of values. + +{{< hint info >}} +Chrome [^1] and Firefox [^2] are still discussing an implementation for a Multi-Keyed Cache while Safari [^3] already runs a version of it since 2013. + +[^1]: Split Disk Cache Meta Bug (Blink), [link](https://bugs.chromium.org/p/chromium/issues/detail?id=910708) +[^2]: Top-level site partitioning (Gecko), [link](https://bugzilla.mozilla.org/show_bug.cgi?id=1590107) +[^3]: Optionally partition cache to prevent using cache for tracking (Webkit), [link](https://bugs.webkit.org/show_bug.cgi?id=110269) +{{< /hint >}} + + +## Relevant Projects + +### Intelligent Tracking Prevention + +[Intelligent Tracking Prevention](https://webkit.org/tracking-prevention/) (ITP) is a privacy feature part of WebKit. It's a conjunction of several tracking prevention features containing a partitioned HTTP Cache which originated from the initial [WebKit Keyed cache from 2013](https://bugs.webkit.org/show_bug.cgi?id=110269). The used keys for the cache are the top frame's eTLD+1 and the origin of each fetched subresource. + +{{< hint warning >}} +Researchers found out attackers [could abuse some ITP features](https://TODO) to infer private user data. +{{< /hint >}} + + + +### First Party Isolation + +First Party Isolation is a [Browser Extension](https://addons.mozilla.org/en-US/firefox/addon/first-party-isolation/) for Firefox which restricts access to cookies and persistent data (e.g cache) per domain. + +## Considerations + +Partitioned HTTP caches are a promising security feature that will eventually land in browsers. These partitioning strategies will mitigate all the XS-Leaks leveraging browsers caches and might be extended to other browser resources which help mitigate resilient attack vectors like the [Socket Exhaustion XS-Leak](https://TODO). + + + +## XS-Leaks Mitigation Overview + +| XS-Leak | Partitioned Cache Mitigation | Full Mitigation | +|:-----------------------------------------------------------------:|:----------------------------:|:-------------------: +| [Frame Counting]({{< ref "../../attacks/frame-counting.md" >}}) | ❌ | ❌ +| [Navigations]({{< ref "../../attacks/navigations.md" >}}) | ❌ | ❌ +| [ID Leaks]({{< ref "../../attacks/id-attribute.md" >}}) | ❌ | ❌ + +### Table Legend + +- **Partitioned Cache Protection** - At least one attack alternative of the XS-Leak can be mitigated +- **Full Mitigation** - Fully mitigates an XS-Leak + + +[^1]: Double-keyed HTTP cache, [link](https://github.com/whatwg/fetch/issues/904) +[^2]: Explainer - Partition the HTTP Cache, [link](https://github.com/shivanigithub/http-cache-partitioning) +[^3]: Client-Side Storage Partitioning, [link](https://privacycg.github.io/storage-partitioning/) diff --git a/content/docs/defenses/opt-in/corp.md b/content/docs/defenses/opt-in/corp.md new file mode 100644 index 000000000..1cd677fd7 --- /dev/null +++ b/content/docs/defenses/opt-in/corp.md @@ -0,0 +1,21 @@ ++++ +title = "Cross-Origin-Resource-Policy" +description = "" +date = "2020-07-21" +category = "defenses" +menu = "main" ++++ + +Cross-Origin-Resource-Policy (CORP) response header enforces [Cross-Origin Read Blocking]({{< ref "../browser-intrinsic/corb.md" >}}) (CORB) as it provides more protection by covering more resources [^1]. Both protect against speculative side-channel attacks (Spectre) by preventing attackers from loading certain cross-origin resources in elements like `script`, `img`, `video`, etc. Unlike CORB, this protection is enforced in the browser only if an application **opts into the protection**. Applications can define which groups of origins (same-site, same-origin, cross-site) are allowed to read their resources. + +If an application sets a certain resource CORP Header as `same-site` or `same-origin`, an attacker origin is incapable of reading that resource because is not part of the CORP group of origins. + +{{< hint info >}} +[Cross-Origin Read Blocking (CORB)]({{< ref "../browser-intrinsic/corb.md" >}}), a similar protection, is an no-opt protection based on heuristics to prevent attackers from loading certain cross-origin resources in unlikely scenarios. +{{< /hint >}} + +{{< hint warning >}} +This mechanism introduced [a new XS-Leak](https://TODO), which allows attackers detect wether CORP was enforced in a certain request. +{{< /hint >}} + +[^1]: Cross-Origin Resource Policy (CORP), [link](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)) \ No newline at end of file