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

[Yoav Nir <[e-mail]>]

Hi Trevor

Excellent summary. I would add one more problem.  

3) Cookie availability to MitB

All requests from the UA to the same server contain the same cookie, and so are deemed to belong to the same session. 

So if I'm connected to webmail.example.com in one browser tab, and also looking attacks.acme.com in another tab, some script or even some plain HTML can cause arbitrary requests to be sent to webmail.example.com, and all these requests are "blessed" by my cookie.

I think if cookiev2 was (at least by default) identified by the triplet (source-origin, target-origin, cookie-name) we would get many less opportunities for cross-site attacks. 


On Jul 18, 2013, at 11:56 AM, Trevor Perrin <[e-mail]> 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