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

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.