W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2013

Re: Adding cookie scope to CSP

From: David Bruant <bruant.d@gmail.com>
Date: Tue, 10 Sep 2013 19:07:30 +0200
Message-ID: <522F51D2.8070308@gmail.com>
To: Devdatta Akhawe <dev.akhawe@gmail.com>
CC: Alex Russell <slightlyoff@google.com>, Anne van Kesteren <annevk@annevk.nl>, "Nottingham, Mark" <mnotting@akamai.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Le 10/09/2013 17:24, Devdatta Akhawe a écrit :
> 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?
I love this idea. Most sane use cases don't need to manipulate cookies 
via JS.
Note that in WebIDL compliant browsers (IE9-ish, IE10, IE11 and 
Firefox), one can do
     delete HTMLDocument.prototype.cookie
before running anything else to achieve the same thing (for browsers 
where this directive isn't supported)

In any case, such a directive is a good idea.

I'd be down for a "disable document.write/ln" directive as well, but 
that's another topic.

David
Received on Tuesday, 10 September 2013 17:08:01 UTC

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