[suborigins] Understanding the syntax

Okay, then I fully understand.

But correct me if I'm wrong here, but isn't this the case already in
Chrome? If you go to a site with cookies sat and view the Network-tab
and have the `Cookies'-field viewable, and then press on a link you'll
see the cookies only for non-cached objects, that is because the
request is cached and does therefore not have any request headers.

cc:ing Mike.

Artur Janc:
>
> 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
>
>

Received on Tuesday, 21 June 2016 22:21:39 UTC