Re: Adding cookie scope to CSP

On 13/09/13 03:04, Nottingham, Mark wrote:
> 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.

Just fyi: websec at the IETF is currently looking at an improvement to
cookies to defend against risk of session hijacking from disclosure of
the session cookie (see also BEAST, CRIME, Lucky-13, ...) and other
risks like e.g. CSRF. (please note: at this stage this is only an open
discussion, the WG has not adopted any documents on this subject yet.)

Several ideas and alternatives currently under discussion are:
1. Some cryptographic binding for cookies, either using asymmetric
crypto (ChannelID) or symmetric (Smart Cookies), to prevent them being
useable when transferred between browsers.
a) Cryptographic binding ("channelID") to the lower transport layer
(e.g. TLS).
b) Smart cookies are bound to the Origin, and cannot be read or written
from other Origins.  Smart cookies are also cryptographically bound to
two TLS connections (The TLS connection on which the server set the
cookie, and the TLS connection on which the client is returning the
cookie).

2. Some origin-binding for cookies to prevent them leaking to
subdomains and being forced by other domains (Origin Cookies).

Cheers, Tobias


>
> Cheers,
>
>
> --
> Mark Nottingham    mnot@akamai.com    http://www.mnot.net/
>
>
>
>

Received on Friday, 13 September 2013 10:27:01 UTC