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