- From: Devdatta Akhawe <dev.akhawe@gmail.com>
- Date: Tue, 10 Sep 2013 16:24:05 +0100
- To: Alex Russell <slightlyoff@google.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, "Nottingham, Mark" <mnotting@akamai.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
I think the GitHub use case is better solved by the sub-origin construct. For example, the cookie changes only allows isolation of individual github users but I can imagine one day also wanting to isolate sub-projects owned by a particular username (e.g., all of Mozilla is a single username with different people with commit rights to different projects). I am also a bit confused by the Path prefix suggestion: if a.b.com/evil wants to set cookies for a.b.com/foo then it can just load the latter in an iframe and execute document.cookie in that frame (thus bypassing the path limitation on the page at a.b.com/evil). If this is not for security but just as a convenience feature, I think we should keep it out of CSP. How about just supporting a "disable document.cookie" directive? thanks Dev On 10 September 2013 16:18, Alex Russell <slightlyoff@google.com> wrote: > Obviously it would be on-top of origin scoping. The idea here would be that > a document could declare that all writes into the cookie jar must be > prefixed with some path. > > > On Tue, Sep 10, 2013 at 7:58 AM, Anne van Kesteren <annevk@annevk.nl> wrote: >> >> On Tue, Sep 10, 2013 at 3:34 PM, Alex Russell <slightlyoff@google.com> >> wrote: >> > Cookies have sub-origin scoping.via the Path attribute. It might be >> > useful >> > to be able to further restrict the ability of script in a page to >> > access/set >> > cookies that are "below" some path. >> >> I'm not sure what this means. The path attribute offers no actual >> protection and definitely does not provide origin-scoping. It's at >> best a convenience feature. >> >> >> -- >> http://annevankesteren.nl/ > >
Received on Tuesday, 10 September 2013 15:24:52 UTC