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

Re: Adding cookie scope to CSP

From: Nottingham, Mark <mnotting@akamai.com>
Date: Fri, 13 Sep 2013 18:47:57 -0500
To: Trevor Perrin <trevp@trevp.net>
CC: Tobias Gondrom <tobias.gondrom@gondrom.org>, "bruant.d@gmail.com" <bruant.d@gmail.com>, "dev.akhawe@gmail.com" <dev.akhawe@gmail.com>, "slightlyoff@google.com" <slightlyoff@google.com>, "annevk@annevk.nl" <annevk@annevk.nl>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <8CFBC3A3-A6E8-40E2-A3FB-1EA2E9AD58BF@akamai.com>
I don't see how CSP is competitive to those more ambitious approaches.

Sent from my iPhone

On 14/09/2013, at 9:12 AM, "Trevor Perrin" <trevp@trevp.net> wrote:

> Hi webappsec,
> Let me second Tobias, and encourage people to look at the cookie
> proposals WebSec is considering.
> Cookie scoping is not just a Javascript problem.  It's also a problem
> when cookies are handled via HTTP headers.
> If we only tackle this problem via CSP, then while "github.com" could
> be protected from user-hosted javascript at "bob.github.com", it won't
> be protected from, say, "test.github.com" being hacked, or
> "mitm.github.com" being invented by a MITM attacker with a forged
> cert.
> So I'd prefer a more comprehensive solution, e.g. something like
> "origin" cookies that scope cookies to origins regardless of whether
> they're set/retrieved via Javascript or HTTP Headers.
> Trevor
> On Fri, Sep 13, 2013 at 3:26 AM, Tobias Gondrom
> <tobias.gondrom@gondrom.org> wrote:
>> 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).
Received on Friday, 13 September 2013 23:48:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:34 UTC