Re: Adding cookie scope to CSP

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:12:37 UTC