Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
Add more isolation policies and fix other errors. (#90)
* Add more isolation policies and fix other errors.

* Too much info

* Change : to = in SameSite

* Clarify that sec-fetch is a hader

* Update content/docs/defenses/isolation-policies/strict-isolation.md

Co-authored-by: jerryzz0 <22921243+jerryzz0@users.noreply.github.com>

* Update content/docs/defenses/isolation-policies/_index.md

Co-authored-by: arturjanc <arturjanc@gmail.com>

* Applied improvements from the review and other tweaks

* typo

* Fix link

* Add embeds in a comment

* Dot and other changes

* Isolation Policies - Editorial pass (#91)

* A new PR for Dirk

* Update _index.md

editorial pass

* Update framing-isolation.md

Editorial pass

* Update resource-isolation.md

Editorial pass

* Update navigation-isolation.md

Editorial pass

* Update strict-isolation.md

Editorial pass

* Update framing-isolation.md

missing comma

Co-authored-by: goedi02 <60691757+goedi02@users.noreply.github.com>

* change order

Co-authored-by: jerryzz0 <22921243+jerryzz0@users.noreply.github.com>
Co-authored-by: arturjanc <arturjanc@gmail.com>
Co-authored-by: goedi02 <60691757+goedi02@users.noreply.github.com>
  • Loading branch information
4 people committed Dec 4, 2020
1 parent 7438d54 commit 9aa02e0
Show file tree
Hide file tree
Showing 6 changed files with 159 additions and 34 deletions.
11 changes: 7 additions & 4 deletions content/docs/defenses/isolation-policies/_index.md
@@ -1,11 +1,14 @@
---
title: "Isolation Policies"
weight: 30
weight: 3
---

# Isolation Policies

This section contains example deployments of isolation policies that make use of the introduced defenses.
This section describes proposed defenses against different kinds of cross-site interactions, presented in the form of _isolation policies_:

* To defend against cross-site requests for common resources (e.g. scripts, images, fetch) with [Fetch Metadata]({{< ref "../opt-in/fetch-metadata.md">}}), check [Resource Isolation Policy]({{< ref "./resource-isolation.md" >}}).
* To defend against cross-site framing with [Fetch Metadata]({{< ref "../opt-in/fetch-metadata.md">}}), check [Framing Isolation Policy]({{< ref "./framing-isolation.md" >}}).
* To defend against cross-site navigational requests with [Fetch Metadata]({{< ref "../opt-in/fetch-metadata.md">}}), check [Navigation Isolation Policy]({{< ref "./navigation-isolation.md" >}}).
* To defend against all cross-site interactions with either [Fetch Metadata]({{< ref "../opt-in/fetch-metadata.md">}}), [SameSite cookies]({{< ref "../opt-in/same-site-cookies">}}), or the Referer header, check [Strict Isolation Policy]({{< ref "./strict-isolation.md" >}}).

* Defend against cross-site framing with Fetch-Metadata, see [Framing Isolation Policy]({{< ref "./framing-isolation.md" >}}).
* Defend against cross-site requests with Fetch-Metadata, see [Resource Isolation Policy]({{< ref "./resource-isolation.md" >}}).
36 changes: 25 additions & 11 deletions content/docs/defenses/isolation-policies/framing-isolation.md
Expand Up @@ -6,30 +6,44 @@ category = [
"Defense",
]
menu = "main"
weight = 2
+++
Framing Isolation Policy supplements [Resource Isolation Policy]({{< ref "resource-isolation.md" >}}) to protect against cross-origin information leaks by
additionally blocking framing requests to non-framable endpoints.
Framing Isolation Policy is a stricter version of [Framing Protections]({{< ref "../opt-in/xfo" >}}) 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.

## Example
It can be combined with [Resource Isolation Policy]({{< ref "resource-isolation.md" >}}) to effectively tighten the attack surface within cross-site information leaks.

The below snippet showcases an example implemention of the Framing Isolation Policy by the application.
{{< hint tip >}}
Instead of rejecting all non-framable endpoints, 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.
{{< /hint >}}

{{< hint tip >}}
When deployed together with [Resource Isolation Policy]({{< ref "resource-isolation.md" >}}), Framing Isolation Policy does not protect against leaks utilizing window references (e.g. `window.length`), so other navigational protections such as [COOP]({{< ref "../opt-in/coop" >}}) or [Navigation Isolation Policy]({{< ref "navigation-isolation" >}}) can be helpful.
{{< /hint >}}

## Implementation with Fetch Metadata

The below snippet showcases an example implemention of the Framing Isolation Policy by an application:

```py
# Reject cross-origin requests to protect from CSRF, XSSI, and other bugs
# Reject cross-site requests to protect from CSRF, XSSI, XS-Leaks, and other bugs
def allow_request(req):
# Allow requests from browsers which don't send Fetch Metadata
if not req['sec-fetch-site'] or not req['sec-fetch-mode'] or not req['sec-fetch-dest']:
if not req['headers']['sec-fetch-site']:
return True
if not req['headers']['sec-fetch-mode']:
return True
if not req['headers']['sec-fetch-dest']:
return True

# Allow non-navigational requests
if req['sec-fetch-mode'] not in ('navigate', 'nested-navigate'):
if req['headers']['sec-fetch-mode'] not in ('navigate', 'nested-navigate'):
return True

# Allow non-frameable requests.
if req['sec-fetch-dest'] not in ('frame', 'iframe', 'embed', 'object'):
# Allow requests not originated from embeddable elements
if req['headers']['sec-fetch-dest'] not in ('frame', 'iframe', 'embed', 'object'):
return True

# [OPTIONAL] Exempt paths/endpoints meant to be served cross-origin.
# [OPTIONAL] Exempt paths/endpoints meant to be served cross-site.
if req.path in ('/my_frame_ancestors_host_src'):
return True

Expand All @@ -38,5 +52,5 @@ def allow_request(req):
```

## Considerations
1. Framing Isolation Policy cannot be applied if an endpoint allows framing requests from specific origins via `X-Frame-Options` and/or Content Security Policy's
Framing Isolation Policy cannot be applied if an endpoint allows framing requests from specific origins via `X-Frame-Options` and/or Content Security Policy's
`frame-ancestors` directive.
40 changes: 40 additions & 0 deletions content/docs/defenses/isolation-policies/navigation-isolation.md
@@ -0,0 +1,40 @@
+++
title = "Navigation Isolation Policy"
description = ""
date = "2020-11-30"
category = [
"Defense",
]
menu = "main"
weight = 3
+++
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.

{{< hint 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.
{{< /hint >}}

## Implementation with Fetch Metadata

The below snippet showcases an example implemention of the Navigation Isolation Policy with the use of [Fetch Metadata]({{< ref "../opt-in/fetch-metadata.md">}}) headers [^secmetadata]:

```py
# Reject cross-site requests to protect from clickjacking, XS-Leaks, and other bugs
def allow_request(req):
# Allow any request that is not cross-site
if req['headers']['sec-fetch-site'] != 'cross-site':
return True

# Allow requests to endpoints meant to be navigated to, e.g. homepage
if req.path in whitelisted_paths:
return True

# Block all top-level cross-site navigations, including embeds
if req['headers']['sec-fetch-mode'] in ('navigate', 'nested-navigate'):
return False

# Allow all other requests
return True
```
## References
[^secmetadata]: Fetch Metadata Request Headers playground, [link](https://secmetadata.appspot.com/)
27 changes: 11 additions & 16 deletions content/docs/defenses/isolation-policies/resource-isolation.md
@@ -1,22 +1,21 @@
+++
title = "Resource Isolation"
title = "Resource Isolation Policy"
description = ""
date = "2020-11-30"
category = [
"Defense",
]
menu = "main"
weight = 1
+++
Resource Isolation Policy prevents your resources from being requested by external websites. Blocking such traffic mitigates common web vulnerabilities such as CSRF,
XSSI, timing attacks, and XS-Leaks. The policy can be enabled for applications whose endpoints are not loaded in a cross-site context and will allow
resource requests coming from your application as well as direct navigations.
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.

## Example
## Implementation with Fetch Metadata

The below snippet showcases an example implemention of the Resource Isolation Policy by the application.
The below snippet showcases an example implemention of the Resource Isolation Policy with the use of [Fetch Metadata]({{< ref "../opt-in/fetch-metadata.md">}}) headers:

```py
# Reject cross-origin requests to protect from CSRF, XSSI, and other bugs
# Reject cross-origin requests to protect from , XSSI, XS-Leaks, and other bugs
def allow_request(req):
# [OPTIONAL] Exempt paths/endpoints meant to be served cross-origin.
if req.path in ('/my_CORS_endpoint', '/favicon.png'):
Expand All @@ -25,29 +24,25 @@ def allow_request(req):
# Safe to set `Cross-Origin-Resource-Policy: same-site`. (see Considerations)

# Allow requests from browsers which don't send Fetch Metadata
if not req['sec-fetch-site']:
if not req['headers']['sec-fetch-site']:
return True

# Allow same-site and browser-initiated requests
if req['sec-fetch-site'] in ('same-origin', 'same-site', 'none'):
if req['headers']['sec-fetch-site'] in ('same-origin', 'same-site', 'none'):
return True

# Allow simple top-level navigations except <object> and <embed>
if req['sec-fetch-mode'] == 'navigate' and req.method == 'GET':
# Allow simple top-level navigations, this includes embeds
if req['headers']['sec-fetch-mode'] == 'navigate' and req.method == 'GET':
return True

# Reject all other requests
return False
```

## Considerations
It should be safe to set a `Cross-Origin-Resource-Policy: same-site` response header on all requests that have not explicitly been exempted from Resource Isolation Policy. See [CORP]({{< ref "../opt-in/corp.md" >}})
It should be safe to set a `Cross-Origin-Resource-Policy: same-site` response header on all requests that have not explicitly been exempted from Resource Isolation Policy. See [CORP]({{< ref "../opt-in/corp.md" >}}).


## Deployment

Check out this [web.dev](https://web.dev/fetch-metadata/) article to learn more about this protection, some different policies, and tips on how to deploy it.

<!-- ## References
[^1]: Protect your resources from web attacks with Fetch Metadata, [link](https://web.dev/fetch-metadata/) -->
73 changes: 73 additions & 0 deletions content/docs/defenses/isolation-policies/strict-isolation.md
@@ -0,0 +1,73 @@
+++
title = "Strict Isolation Policy"
description = ""
date = "2020-11-30"
category = [
"Defense",
]
menu = "main"
weight = 4
+++
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.

{{< hint 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.

However, this would only work for navigational requests, since other resources are loaded in the background.
{{< /hint >}}


## Implementation with Fetch Metadata

The below snippet showcases an example implementation of Strict Isolation Policy by an application:

```py
# Reject cross-origin requests to protect from CSRF, XSSI, and other bugs
def allow_request(req):
# Allow requests from browsers which don't send Fetch Metadata
if not req['headers']['sec-fetch-site']:
return True

# Block any cross-site request
if req['headers']['sec-fetch-site'] == 'cross-site':
return False

# Allow all other requests
return True
```

## Implementation with SameSite cookies
If a server sends a cookie with the [`SameSite=strict`]({{< ref "../opt-in/same-site-cookies/#samesite-cookie-modes" >}}) flag, any returned request that doesn't contain that cookie can be rejected, as showcased in this snippet:

```py
# Reject cross-origin requests to protect from CSRF, XSSI, and other bugs
def allow_request(req):

if req['cookies']['strict-cookie'] == 'true':
return True

# Block requests without a strict cookie
return False
```

## Implementation with Referer
It is also possible to reject requests from untrusted origins with the [`Referer`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer) header:

```py
# Reject requests that came from untrusted referrers
def allow_request(req):

# check if the referer header is trusted, i.e. exists in trusted_referers dict
if req['headers']['referer'] in trusted_referers:
return True

# Block requests without a strict cookie
return False
```

{{< hint important >}}
It is not guaranteed that every request will contain the Referer header (e.g. extensions can strip the header) which could potentially break an application. Also be aware that it is possible to set the value of `Referer` to `null`.

Twitter deployed [^twitter_silhouette] a similar protection against XS-Leaks.
[^twitter_silhouette]: Protecting user identity against Silhouette, [link](https://blog.twitter.com/engineering/en_us/topics/insights/2018/twitter_silhouette.html)
{{< /hint >}}
6 changes: 3 additions & 3 deletions content/docs/defenses/secure-defaults/_index.md
@@ -1,11 +1,11 @@
+++
title = "Secure Defaults"
weight = 2
weight = 10
+++

# Secure Defaults

This section contains articles discussing two types of secure defaults:

* [Partitioned Caches]({{< ref "./partitioned-cache.md" >}}) – Ensure that cache resources cannot be shared in between different sites.
* [Cross Origin Read Blocking (CORB)]({{< ref "./corb.md" >}}) – Prevents certain types of responses from being referenced by certain classes of requests.
* [Partitioned Caches]({{< ref "./partitioned-cache.md" >}}) – Ensure that cache resources cannot be shared in between different sites.
* [Cross Origin Read Blocking (CORB)]({{< ref "./corb.md" >}}) – Prevents certain types of responses from being referenced by certain classes of requests.

0 comments on commit 9aa02e0

Please sign in to comment.