Re: [websec] Cookies: What is to be done?

[Hannes Tschofenig <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Trevor, 

nice writeup!

There is also a relationship to the work we are doing in the OAuth working group. 
Here is the relevant document: 
http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-04

The OAuth work (obviously) has a different story on how the parties actually get the key. There are, obviously, various reasons why people use cookies. 

Ciao
Hannes

On Jul 18, 2013, at 10:56 AM, Trevor Perrin wrote:

> Hi,
> 
> I tried to send this earlier, but I don't think it went through.
> 
> Here's an attempt to summarize the main cookie problems and proposals.
> 
> I'd be interested if anyone sees thing differently.
> 
> 
> Problems
> =========
> 
> 1) Bearer token problem:
> Cookies are transmitted frequently, and if a transmitted cookie is
> somehow stolen, it could be used by an attacker.
> 
> 2a) Cookie scoping (confidentiality):
> Cookies set on example.com will typically be sent to all subdomains of
> example.com.  So the security of example.com can be undermined by
> less-secure subdomains.  Even HSTS/HPKP/TACK/DANE for example.com
> could be undermined if a hacker can take over test.example.com, or a
> MITM can invent badguy.example.com, since the browser would hand these
> attackers the example.com session cookie.  There are partial
> mitigations for this, but nothing that could work reliably across all
> sites and browsers:
> 
>  - Omitting the cookie's "Domain" attribute will cause cookies to be
> sent only to "example.com" and not its subdomains (RFC 6265), on all
> browsers except IE.   IE seems unwilling to change this, presumably
> due to legacy web apps.
> 
>  - Setting a cookie's "Secure" attribute will require the browser to
> only transmit it over SSL/TLS. However, the subdomain may not have the
> same HSTS/HPKP/TACK/DANE/etc requirements as its parent.  HSTS and
> HPKP provide "includeSubdomains" to address this (RFC 6797, 14.4).
> However, it's common for example.com to have subdomains that can't
> comply with HSTS or HPKP (for example: mobile.example.com doesn't use
> SSL; images.example.com is hosted on a CDN; test.example.com has a
> self-signed cert, etc).  In these cases, "includeSubdomains" can't be
> used.
> 
> 2b) Cookie scoping (integrity):
> Cookies set on webmail.example.com can be overwritten or deleted by
> its subdomains, regardless of the "Secure" or "Domain" attributes.
> Also, example.com and its subdomains could set an identically-named
> cookie for Domain=example.com, which will get sent to
> webmail.example.com.  "Forcing" a cookie on the victim could allow an
> attacker to log a victim into the attacker's account.  The victim
> might then enter credit card numbers or other data, similar to the
> "login CSRF" attacks in [1].
> 
> This is harder to mitigate than 2a, as "Domain" and "Secure"
> attributes have no effect, and the scope of hostnames that can affect
> a victim hostname is not just the victim's subdomains, but everything
> sharing the same TLD+1 domain (*.example.com, in this case).
> 
> 
> Proposals
> ==========
> 
> 1) Origin Cookies:
> http://tools.ietf.org/html/draft-abarth-cake-01
> http://w2spconf.com/2011/papers/session-integrity.pdf
> 
> This adds an "Origin" attribute to cookies.  Such cookies are
> backwards-compatible with old browsers.  New browsers would only
> return them to the hostname that set them, via an "Origin-Cookie"
> header, thus fixing 2a.  To fix 2b, the browser might have to always
> send something like "Origin-Cookie-Support: true" as an HTTP header,
> so that an Origin Cookie supporting server would know to disregard
> old-style cookies that might have been forced on the browser.
> 
> This doesn't fix the "bearer token" aspect of cookies, but it seems a
> simple, clean fix to the scoping problems.  What happened to this?
> 
> 
> 2) ChannelID
> http://tools.ietf.org/html/draft-balfanz-tls-channelid-01
> 
> The browser adds an ECDSA public key and signature to every TLS
> handshake.  The server can implement "Channel-bound cookies" which are
> associated with the public key.  Such cookies can't be transferred
> from one browser to another.
> 
> This solves the "bearer token" aspect of cookies.  It also solves a
> big part of the scoping problem, since an attacker can't steal usable
> cookies, or force her cookies on someone else.  However, since the
> same ChannelID public key is used for an entire TLD+1, an attacker who
> could hack subdomain hosts or perform MITM could still:
> - Delete cookies
> - Steal a cookie from a user at A.example.com, and force it on the
> same user at B.example.com
> - Steal a cookie via a subdomain and then force it later on the same
> user to "rollback" to an earlier state
> 
> This also modifies the TLS stack, and adds a client-side signature
> computation to every TLS session.
> 
> 
> 3) Session Continuation Protocol
> http://tools.ietf.org/html/draft-williams-websec-session-continue-proto-00
> 
> Instead of cookies, the server can set a symmetric "session key" into
> the browser, and specify a range of hostnames to use it for.  The
> browser will send a nonce, and a MAC over the nonce, for every
> connection to those hostnames.
> 
> Since the nonce and MAC, if stolen, would suffice as a bearer token,
> this doesn't solve 1.  Since the Host-Scope of the session can be
> specified arbitrarily, this solves 2a but not 2b.
> 
> 
> 4) HTTP Session Management
> http://tools.ietf.org/html/draft-hallambaker-httpsession-01
> 
> This is similar to (3), except the MAC can optionally be calculated
> over "portions of the HTTP message", and the scoping rules are defined
> to be identical to cookies as defined somewhere (not specified).  This
> might mitigate 1 somewhat, since a MAC, if stolen, could only be used
> to replay requests similar to the stolen one.  Cookie scoping problems
> don't seem to be addressed.
> 
> 
> Trevor
> 
> 
> [1] http://seclab.stanford.edu/websec/csrf/csrf.pdf
> _______________________________________________
> websec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/websec

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJR57Q6AAoJEGhJURNOOiAt+mgIAKEm3q1CoSMDkthRkh6IPYWE
HNcQcKiyCow0SnWfZ5LytduYoT1zKWIjr5e6L+6DAPIVx1xm3WnNjOhofnle6oHk
UFhCG1qFLT3yriyoY24544wboGRIvvpiOoiueAhRPNsxra4bZVTCb0xFttc8QgFH
3jZ6SITAinPuLmU6nNYkuOM0vHBypeSUvnkNcX5HHbyE9b1rMsNNuQB1VOVEuKFA
AatH/5k2Gd1rJGmgvgWo7Cxc9g+xnMEeGJVZ/4aSk3lTXQpJt78EIQTPBMLSns6A
Hb6uXxhhJCVgpOf2mOwDPa6Zc+y2KSfAz94V1ooRgtmACM03AzQw+vdF0Ze7tHs=
=tuMj
-----END PGP SIGNATURE-----