Add allow-unique-origin keyword in iframe/CSP sandbox

[shhnjk]

Up-to-date details and FAQ for this proposal is available at https://github.com/shhnjk/allow-unique-origin

Proposal

Add a new sandbox keyword, allow-unique-origin, that causes the rendered content to execute in a unique non-null origin.

The origin of a document sandboxed in this way will be sandbox:["$RANDOM_UUID","$PRECURSOR_ORIGIN"]. For example, if https://example.com set a CSP: sandbox allow-unique-origin header, then the origin of the document would be sandbox:["9138ee47-c4f7-4e30-8751-acf51834e3f6","https://example.com"]. Having a unique origin that contains the precursor origin, makes it possible to implement a number of useful product features like checking the precursor origin when responding to CORS requests.

These sandboxed pages will have access to isolated new storage partitions with a lifetime scoped to the current page. This includes document.cookie, window.localStorage, window.caches, and more.

Why do we need this?

It aims to solve three problems.

1. A web-platform alternative to sandbox domains

Many Web apps require a place to host user contents (e.g. usercontent.goog, dropboxusercontent.com, etc) to safely render them. In order to do so securely (e.g. to avoid exploitable XSS, cookie bombing, and Spectre attacks), many sites rely on sandbox domains to get unique origins. Sandbox domains entail significant complexity for authentication (especially if one also adds it to the public suffix list) and are very hard to do right. Adding the ability to create iframes and top level pages with unique origins can replace this complexity with a native Web platform API.

2. Increasing the applicability of sandboxing

CSP sandbox is widely used for isolating content, but running in a null origin significantly limits many uses:

• Sandboxed content can't access any storage APIs. Many third-party scripts (e.g. analytics scripts) rely on being able to access these APIs, so it becomes impossible to sandbox these pages.
• Sandboxed content sends requests with a Origin: null header, so there is no way for services to make fine grained decisions based on exactly what content is executing in a given sandboxed page.

Supporting a unique origin, fixes both of these limitations and will enable more services to use sandboxing to isolate untrusted content.

3. XSS through Blob URLs

While this needs to be discussed separately in the File API spec, we plan to propose a way to add headers to Blob object. Blob URLs are useful for loading locally available resources. However it also leads to XSS bugs when Blob URLs are created with untrusted content.

1. XSS on WhatsApp Web.
2. XSS on Shopify.
3. XSS on chat.mozilla.org.

If we can add a CSP header to Blob object with allow-unique-origin keyword, it's possible to create sandboxed Blob URLs that are guaranteed not to cause an XSS (because any JS will execute in a unique origin).