[suborigins] Protecting Suborigined content from the rest of the origin

# Aleksandr Dobkin (5 days ago)

The current spec is great for isolating suborigined content from the rest of the domain, and thereby preventing XSS bugs in the suborigined content from being used to attack the rest of the domain. The opposite, protecting suborigined content from being affected by XSS bugs in the rest of the domain, is also very useful. A prime example is protecting password-change and OAuth2 authorization pages from being attacked by XSS bugs elsewhere on the domain.

The spec already provides several protections: 1) JS content in the same physical original cannot directly access the DOM and 2) .postMessages() messages can be discriminated by .origin. The one additional thing that we need is a way to block non-suboringed JS from fetching using XHR from the suborign. If non-suborigined content can fetch arbitrary content, it can also typically fetch CSRF tokens and arbitrary sensitive information from the suborigin.

I propose we extend the XHR spec to block returning of responses to JS if the response contains a Suborigin header, and suborigin value does not match suborigin name of the requester document.

This blocking is similar to how it is done for simple XHRs when the response does not have CORS headers.

Contact us to advertise here
# Artur Janc (4 days ago)

On Mon, May 15, 2017 at 11:26 PM, Aleksandr Dobkin dobkin@google.com

wrote:

The current spec is great for isolating suborigined content from the rest of the domain, and thereby preventing XSS bugs in the suborigined content from being used to attack the rest of the domain. The opposite, protecting suborigined content from being affected by XSS bugs in the rest of the domain, is also very useful. A prime example is protecting password-change and OAuth2 authorization pages from being attacked by XSS bugs elsewhere on the domain.

The spec already provides several protections: 1) JS content in the same physical original cannot directly access the DOM and 2) .postMessages() messages can be discriminated by .origin. The one additional thing that we need is a way to block non-suboringed JS from fetching using XHR from the suborign. If non-suborigined content can fetch arbitrary content, it can also typically fetch CSRF tokens and arbitrary sensitive information from the suborigin.

I propose we extend the XHR spec to block returning of responses to JS if the response contains a Suborigin header, and suborigin value does not match suborigin name of the requester document.

This blocking is similar to how it is done for simple XHRs when the response does not have CORS headers.

I like this idea -- making the protection of suborigins bidirectional (not just protecting the rest of the origin from an application in the suborigin, but also the suborigined app itself) could be a big benefit. One of the uses of suborigins we've discussed in the past is protecting administrative UIs co-hosted in domains with user-facing applications; if putting such UIs in a suborigin improves their own security, it gives developers a more compelling reason to adopt the feature.

Two notes about this:

  • My memory is fuzzy but I think one of the issues that we were worried about was that Service Workers from the main origin would be able to intercept responses from the suborigin because they would appear as same-origin. However, since the threat model we're worried about is an XSS in the main origin, this shouldn't be a big problem because most XSS bugs shouldn't be able to trigger the installation of a malicious service worker because of origin restrictions on SW loads. Also, I believe the current path scoping of SWs makes it unlikely that even if an attacker can install one, it would be able to affect resources in a suborigin (this is not a guarantee in the general case, but should be true for most realistic suborigin deployments).

  • I wonder about an escape hatch for responses that would end up serving from a suborigin (and would return a Suborigin header) but would need to be accessible via XHR by the main origin. If the restriction could be lifted via a CORS-like response header to allow other suborigins to access the response, we'd make things safe by default by also allow for easier adoption in such cases.

# Aleksandr Dobkin (3 days ago)

Should ServiceWorkers from non-suborigined content be able to intercept fetches initiated from a suborigin? I have the feeling that the answer should be "no". It seems cleaner and safer to restrict workers per origin/suborigin.

Even if SW get access to sub-origin fetches, XSS there are not very common, so overall risk is probably low.

Want more features?

Request early access to our private beta of readable email premium.