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

Re: [suborigins] Understanding the syntax

From: Artur Janc <aaj@google.com>
Date: Tue, 21 Jun 2016 13:28:07 +0200
Message-ID: <CAPYVjqq3cBJ1sVG868HSFRGBuDmERXDCcKJEHKXrk2BxN7eo6g@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: chloe <chloe@chloe.re>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Devdatta Akhawe <dev@dropbox.com>, Joel Weinberger <jww@google.com>
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 11:28:56 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:20 UTC