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

Re: Adding cookie scope to CSP

From: Nottingham, Mark <mnotting@akamai.com>
Date: Thu, 12 Sep 2013 20:04:50 -0600
To: David Bruant <bruant.d@gmail.com>
CC: Devdatta Akhawe <dev.akhawe@gmail.com>, Alex Russell <slightlyoff@google.com>, Anne van Kesteren <annevk@annevk.nl>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <E174E845-24CC-4A03-A44A-CD16CCD5D6CE@akamai.com>

On 11/09/2013, at 3:07 AM, David Bruant <bruant.d@gmail.com> wrote:

> 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).

Suborigin is certainly interesting, and its interaction with cookies will need to be discussed.

However, this is a bit different; cookies *already* are allowed to span several origins, not just one; this proposal is flipping a bit to indicate that they're confined to one suborigin. In that sense, I'm happy to modify it to say they're confined to one origin *or* suborigin (if in use).


>> 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.

Agreed, I think.


>> 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.

I don't know. I could see folks using Github or hosting providers being unpleasantly surprised when document.cookie doesn't work *at all*; lots of frameworks provide interfaces to it / assume its availability, and when used within the origin, it isn't a security problem.

It seems to me that the policy ought to be designed in such a way as to be minimally intrusive as possible, while still meeting the security goals. Disabling document.cookie puts the hoster into an unpleasant position of fielding a lot more support requests because things don't work as expected, if they want to improve security.


> 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.


That does sound interesting.

Cheers,


--
Mark Nottingham    mnot@akamai.com    http://www.mnot.net/
Received on Friday, 13 September 2013 02:05:44 UTC

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