W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2016

[suborigins] Understanding the syntax

From: chloe <chloe@countermail.com>
Date: Tue, 21 Jun 2016 17:57:13 +0200
To: public-webappsec@w3.org
Message-ID: <0b2a8cf0-54b5-d125-2acc-32f620557a5e@countermail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:56 UTC