Add CORB, CORP and Partitioned Caches Defense Articles to the Wiki

content/docs/defenses/browser-intrinsic/corb.md

@@ -6,4 +6,26 @@ category = "defenses"
 menu = "main"
 +++
 
-TODO
+
+## 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)

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.
+
+<!--TODO(manuelvsousa): Add reference to cache probing attacks-->
+
+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 >}}
+
+<!--TODO(manuelvsousa): ADD ITP XS-Leak here -->
+
+### 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).
+
+<!--TODO(manuelvsousa): Add socket exhaustion ?-->
+
+## 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/)

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))