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