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

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.

On Tue, May 16, 2017 at 2:58 AM, Artur Janc <aaj@google.com> wrote:

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