Re: [suborigins] Understanding the syntax

On Tue, Jun 21, 2016 at 12:42 PM, Mike West <> wrote:

> +Dev and Joel (though the latter is out of office for the next ~month).
> -mike
> On Mon, Jun 20, 2016 at 11:23 AM, chloe <> wrote:
>> Hello,
>> the draft states the following as an example:
>> >To address this, the developers decide to serve both applications on
>> two separate suborigins. For all HTTP requests to any subpath of /chat
>> or /shopping, includes a header suborigin: chat or
>> suborigin: shopping, respectively.
>> I have a hard time understanding this example.
>> Example: I have /foo that serve different content and is public. /foo
>> don't require any cookies because it's public. However, my / does
>> require cookies as authentication. If an attacker finds XSS on /foo,
>> will the attacker have the possibility to read cookies that are used as
>> authentication on / if the header "suborigin: foo" is sent only on the
>> /foo subpath?
By default the attacker will not be able to read cookies because documents
in suborigins are cookie-averse: In your scenario, when
the attacker attempts to read document.cookie on /foo, it will return an
empty string.

Note that suborigins also provide an 'unsafe-cookies' option ( which makes it
possible for a developer to opt out of this (safe) behavior. This can
sometimes be helpful if you want to share non-sensitive cookies between
suborigins, and if the authentication cookie is marked as HttpOnly. In this
case, an attacker with an XSS in a suborigin still won't be able to read
the main auth cookie value since it's hidden from client-side code.


Received on Tuesday, 21 June 2016 11:28:56 UTC