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

Re: Adding cookie scope to CSP

From: Nottingham, Mark <mnotting@akamai.com>
Date: Mon, 16 Sep 2013 22:02:47 -0500
To: Trevor Perrin <trevp@trevp.net>
CC: Erik Nygren <erik+w3@nygren.org>, Tobias Gondrom <tobias.gondrom@gondrom.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <523ED8C8-4995-4C0E-A1F4-689C0ACE31B4@akamai.com>

On 17/09/2013, at 12:06 PM, Trevor Perrin <trevp@trevp.net> wrote:

> On Sat, Sep 14, 2013 at 7:45 AM, Erik Nygren <erik+w3@nygren.org> wrote:
>> 
>> In particular, a frustrating aspect
>> of cookies today is that they follow a different set of rules than one
>> might expect from Origin policies.  While this is necessary, there are
>> cases where being able to limit cookies set by content to obey origin
>> policies would be highly valuable.
> 
> Agreed that origin scoping of cookies would be valuable.
> 
> But doesn't it make more sense to declare this policy for the cookies
> you're trying to protect (e.g. "Origin Cookies"), than to declare it
> on every page that might attack the cookies you're trying to protect?

The use case here is that a hosting provider doesn't fully trust the content, and wants to prevent cookies being set cross-domain. They do NOT want the content to have to modify how it uses cookies, as long as they're well-behaved; adding a CSP header on all outgoing responses does this with minimal intrusion.

> Every host under a public suffix can set cookies which are sent to all
> other hosts under that suffix.  So to protect cookies on
> "webmail.example.com" with CSP, you'd have to worry about CSP policy
> for every page under "example.com".  And this still wouldn't protect
> you from rogue, hacked, or MITM-invented webservers under
> "example.com".
> 
> In contrast, if a webserver sets "origin" cookies at
> "webmail.example.com" and ignores non-origin cookies, then it becomes
> immune to whatever related domains do with cookies.  It doesn't have
> to declare new CSP policies on related domains, and it gets protection
> against all related-domain attacks, not just javascript.


That's not the use case; it requires the application -- especially, the frameworks the application uses -- to be modified.

It's an interesting case, mind you; I just think it's separate.

Cheers,

--
Mark Nottingham    mnot@akamai.com    http://www.mnot.net/
Received on Tuesday, 17 September 2013 03:03:18 UTC

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