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

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

@@ -6,4 +6,24 @@ 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 impossible 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 but when it detects a page does not serve a `nosniff` header it detects 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 >}}
+An important complement of CORB is the [Cross-Origin Resource Policy (CORP)]({{< ref "../opt-in/corp.md" >}}).
+{{< /hint >}}
+
+
+## Considerations
+
+{{< hint danger >}}
+CORB introduced a [new set of XS-Leaks](https://TODO) since attackers are able to observe when a request is blocked or allowed by CORB. This leads to information leaks when CORB blocks certain requests depending on user information the attacker is after.
+{{< /hint >}}
+
+[^1]: Cross-Origin Read Blocking for Web Developers, [link](https://www.chromium.org/Home/chromium-security/corb-for-developers)

content/docs/defenses/browser-intrinsic/partitioned-cache.md

@@ -0,0 +1,60 @@
++++
+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 restrict the cache usage to a certain group of origins or use [some workarounds]({{< ref "../design-protections/subresource-protections.md" >}}) to protect resources, which come with tradeoffs. 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 double keys such as `top-frame origin` and URL, however, other keys and strategies (triple keys) have also been considered.
+
+[Chrome](https://bugs.chromium.org/p/chromium/issues/detail?id=910708) and [Firefox](https://bugzilla.mozilla.org/show_bug.cgi?id=1590107) are still discussing an implementation for a Multi-Keyed Cache while [Safari](https://bugs.webkit.org/show_bug.cgi?id=110269) already runs a version of it since 2013.
+
+
+<!--TODO(manuelvsousa): Add socket exhaustion ?-->
+
+## 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 to 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 if the defense mechanism would exist
+- **Full Mitigation** - Fully mitigates an XS-Leak if the defense mechanism would exist
+
+
+[^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,16 @@
++++
+title = "Cross-Origin-Resource-Policy"
+description = ""
+date = "2020-07-21"
+category = "defenses"
+menu = "main"
++++
+
+
+## Explanation
+
+Cross-Origin-Resource-Policy (CORP) response header is a complement of [Cross-Origin Read Blocking]({{< ref "../browser-intrinsic/corb.md" >}}) (CORB). CORP allows applications to **opt into the protection** for resources that might not be covered automatically by CORB[^1]. Applications can define which origins are allowed to read their resources.
+
+If an application sets a certain resource CORP Header as `same-site`, an attacker is incapable of reading that resource because it's in a different origin.
+
+[^1]: Cross-Origin Resource Policy (CORP), [link](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP))