- From: David Bruant <bruant.d@gmail.com>
- Date: Tue, 10 Sep 2013 19:07:30 +0200
- 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