Re: [suborigins] Understanding the syntax

On Tue, Jun 21, 2016 at 12:42 PM, Mike West <mkwst@google.com> 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 <chloe@chloe.re> 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, example.com 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:
https://w3c.github.io/webappsec-suborigins/#cookies. 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 (
https://w3c.github.io/webappsec-suborigins/#unsafe-cookies) 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.

Cheers,
-Artur