- From: chloe <chloe@countermail.com>
- Date: Tue, 21 Jun 2016 17:57:13 +0200
- To: public-webappsec@w3.org
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