Sandbox resources loaded via a path gateway

[lidel]

Motivation

Websites loaded via path gateway are able to access cookies and storage of the entire domain. While we are moving to subdomain gateways (#89), requests made to path gateways will continue to lack origin isolation between content roots. Some will be redirected to subdomain ones, but we should look into other means of improving the situation.

TL;DR

1. subdomain gateways will provide Origin isolation
2. path gateways do not
3. Various headers can be leveraged for limiting what can be used on the origin of path gateway.

Headers to investigate

Clear-Site-Data header

The Clear-Site-Data header clears browsing data (cookies, storage, cache) associated with the requesting website. It allows web developers to have more control over the data stored locally by a browser for their origins.
– https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Clear-Site-Data

We could leverage Clear-Site-Data header and send a hint to user agent to clear any preexisting cookies and storage. This is a "nuclear option", but could incentivize users to switch to subdomain gateways when access Web APIs relying on Origin is required.

Note: this requires native subdomain support (ipfs/kubo#6498) to land first.

To purge cookies and storage without reloading any contexts, below header would be returned with every response from /ipfs/{cid} and /ipns/{foo} paths:

Clear-Site-Data: "cookies", "storage"

Content-Security-Policy

Disabling JS and various security features.

Ref. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

Highlights:

• sandbox directive may be the most elegant way, it would apply the same logic as <iframe> sandbox for entire page.

Prior art:

• blogpost: https://blog.web3.storage/posts/badbits-and-goodbits-csp-in-w3link
• web3.storage returns:
  • content-security-policy: default-src 'self' 'unsafe-inline' 'unsafe-eval' blob: data: https://*.w3s.link https://*.nftstorage.link https://*.dweb.link https://ipfs.io/ipfs/ https://*.githubusercontent.com https://tableland.network https://*.tableland.network ; form-action 'self'; navigate-to 'self'; connect-src 'self' blob: data: https://*.w3s.link https://*.nftstorage.link https://*.dweb.link https://ipfs.io/ipfs/ https://*.githubusercontent.com https://tableland.network https://*.tableland.network ; report-to csp-endpoint ; report-uri https://csp-report-to.web3.storage
  • reporting-endpoints: csp-endpoint="https://csp-report-to.web3.storage"

Feature-Policy

Another way of disabling various APIs and behaviors

Ref. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy

• Relaxing the same-origin restriction requires mutual opt-in from two websites. Still, it would not hurt if we explicitly disabled this via [Feature-Policy/document-domain](Ref. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy/document-domain) (dweb.link is on https://publicsuffix.org/, but other gateways may not be)

TODO

• create PoC proxy to validate the idea
  • setting Gateway.HTTPHeaders in go-ipfs config may be enough for initial tests
• document behavior in Firefox (
• document behavior in Chromium
• document behavior in Safari

[lidel]

Blocking cookies is a nuclear option that may break some deployments behind reverse proxies that pass all headers. We would need NoWebSecurity flag (false by default) in case someone really wants to disable things like Clear-Site-Data in contexts that provide no origin isolation.

[lidel]

Something to be aware of: executionContexts and wildcard directives are not recognized by Chromium (bug-898503)

[lidel]

Interesting fact: w3c spec suggests a discrepancy between clearing cookies and storage:
https://www.w3.org/TR/2017/WD-clear-site-data-20171130/#grammardef-storage
https://www.w3.org/TR/2017/WD-clear-site-data-20171130/#grammardef-cookies

According to the spec storage is supposed to be purged for origin, while cookies cleanup is listed as origin + all origins based on subdomains of the current one.

I tested behavior in Chromium 76 and Firefox 74 to see if it negatively impacts subdomain gateways in go-ipfs (ipfs/kubo#6096). This does not seem to be the case: subdomain cookies are not purged if Clear-Site-Data is present in localhost/ipfs/$cid 301 response.