Re: Suborigin update

There are a couple more cases that would useful to document:
* workers/service workers - I assume the origin will be suborigin if one
exists
* how is X-Frame-Options header interpreted in light of suborigins - does
one list suborigins explicitly in the header
* what would be the interaction (if any) between suborigins and two iframes
setting document.domain to try to set effective script origin



Jasvir Nagra
http://www.cs.auckland.ac.nz/~jas

On Thu, Nov 12, 2015 at 2:43 PM, Joel Weinberger <jww@chromium.org> wrote:

> Hi WebAppSec folks. I believe we're scheduled to discuss Suborigins in
> part of our next meeting on Monday. Before that, I wanted to give you a
> small update to get you up to speed.
>
> I've been working with Mike West and Artur from Google Security to
> understand some real use cases for Suborigins. The design we've been
> working on of late is, more or less, to treat Suborigins as much as
> possible as a separate origin from the top level origin, with a few notable
> exceptions and opt-outs. Here they are (pretty much taken from Artur):
>
> - document.cookie is necessary for applications to keep working without
> requiring users to sign into every part of your website separately.
> Security-wise it's on par with existing behavior (cookies being shared
> between subdomains) so we believe it's a reasonable default. That having
> been said, I wouldn't be surprised based on comments from Dev that we'll
> eventually want to build an opt-out to give a Suborigins a unique cookie
> jar.
>
> - XHR/Fetch and postMessage: These two are likely to generate the biggest
> challenge for existing applications and we want to allow applications to
> adopt Suborigins without making significant client-side changes (ideally,
> no client-side changes at all). You should be able to put your application
> in a suborigin by adding the Suborigin header, and possibly whitelisting
> your suborigin to access endpoints you currently request with XHR, and get
> almost all of the benefit of (sub)origin separation when it comes to XSS.
>
> In the case of XHR/Fetch, our solution is to send a CORS preflight for all
> XHR/Fetch calls from a Suborigin, and we'll add a Suborigin header. Then
> we'll require that the response has an Access-Control-Allow-Suborigin
> header that lists the requesting Suborigin (or, alternatively, a '*'
> response to Access-Control-Allow-Origin).
>
> For postMessage, we'll, by default, serialize the Suborigin into the
> event.origin field. We'll also provide a separate event.suborigin field to
> more easily check that value. However, if that's problematic for some
> applications, we'll provide a directive, such as
> 'unsafe-postMessage-serializatiion' that will leave the event.origin field
> on receipt as a regular origin, without the Suborigin serialized into it,
> leaving it to check the event.suborigin field on its own.
>
> - localStorage: Every Suborigin gets a fresh localStorage jar. If that's
> problematic, can consider a 'unsafe-share-localStorage' directive.
>
> As a strawman example to explain these decisions, imagine an application
> Foo hosted at https://www.google.com/foo (which uses XHR, possibly has
> some XPC with postMessage, etc). It's self-contained in that its XHRs are
> sent only to its own endpoints (namely only to Foo's own servers), and
> postMessage is usually sent to other pages in the same app. This XHR and
> postMessage design would allow it to maintain its current deployment with
> really only changes to the server, and very few changes to the app itself.
> Importantly, the app will need to have the cookie because otherwise you'd
> stop being logged in and it would suck for usability.
>
> Let us know what you think, and we can discuss on Monday.
> --Joel
>