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

From: Trevor Perrin <[email-masked]>
Date: Thu, 18 Jul 2013 01:56:32 -0700

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 18 Jul 2013 11:24:10 +0200

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:

> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: Yoav Nir <[email-masked]>
Date: Thu, 18 Jul 2013 14:04:34 +0000

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.

---

From: Trevor Perrin <[email-masked]>
Date: Thu, 18 Jul 2013 16:22:13 -0700

> Excellent summary. I would add one more problem.
[...]
> 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

Hi Yoav,

So in a word: "CSRF"?

> 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.

By "source-origin" you mean the referrer?

I'm not sure session-continuation is the right place to address CSRF,
since CSRF can happen even without a session (see "Login CSRF" from
[1]).  That makes me think associating an HTTP request with a
"referrer" is orthogonal to the problem of associating a request with
a "session".

Also, I think good CSRF mitigations exist, so it's not as pressing a
problem, whereas cookie scope problems can undo a lot of the benefit
of HSTS and pinning.

Trevor

---

From: Yoav Nir <[email-masked]>
Date: Fri, 19 Jul 2013 05:51:26 +0000

>> 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 webm…

Not exactly. I think it's architecturally wrong that the same cookie (or rather, session) is used for all requests from a server. Yes, this facilitates CSRF, but it also makes it harder for a website to give you different services based on where the requests originate. I would have liked to have a different session with facebook when I'm directly connected to facebook.com vs when I'm fetching a "Like" button for the bottom of some article on my favorite news site. By tracking referrer-cookie pairs, this allows Facebook to track what I'm reading, even if I never click any of those "Like" buttons.

To solve the different sessions for different referrers, we could just have the websites treat the referrer-cookie pair as the session identifier, without any changes to the UA or the protocol, but that would not solve the privacy issue. 

OTOH that would make life harder for Facebook. First, tracking is a part of their business (and any other business that relies on targeted advertising), but we'd have to think about how the "Like" buttons could still be made to work (and whether we care about it)

Yoav

---

From: Tobias Gondrom <[email-masked]>
Date: Fri, 19 Jul 2013 15:46:31 +0800

> Not exactly. I think it's architecturally wrong that the same cookie (or rather, session) is used for all requests from a server. Yes, this facilitates CSRF, but it also makes it harder for a websi…

Hm, seems we have two issues here: one is security and one is privacy.
For security against CSRF, I think the common solution of the hidden
token field is actually doing it's job quite ok. So not sure we need
another solution against CSRF. And secondly, I have the feeling that not
sending cookies to a domain where they originate from would mean a major
paradigm shift and could possibly break a lot of web applications.
The second issue of privacy: I would agree that it is potentially bad
that you can track user behaviour via displayed images and the cookies
without any actions or consent of the user. But not sure we can really
fix that.
Just my 5 cents, Tobias

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 21 Jul 2013 21:13:39 -0400

The reason the Session header mechanism I propose does not address cookie
scoping is that there is already a perfectly adequate confidentiality and
integrity solution in the hands of the Server: encrypt the cookie contents
and append a MAC to the end.

The only situation where I see cookie stealing as a problem is where the
cookie is a bearer token. Since the client never looks at cookie content
there is no good reason not to encrypt if the data is at all confidential.

Cookie overwriting is a little more complicated as merely being able to
detect overwriting is not the same as being able to prevent a denial of
cookie attack.

If people think the existing scope mechanism in cookies is insufficient, I
am open to extending the Session draft to add an origin cookie type
capability. Or we can redefine the cookie handling as well if that is
needed to ensure backwards compatibility.

On the issue of preventing replay attacks, the session continuation draft I
wrote describes two application scenarios. The first being the Web browser
scenario, the second being Web Services.

The Web service I have developed that uses the draft uses nonces passed in
the protocol to prevent replay attacks. Web Services typically require much
stronger replay attack prevention than Web Browsing. But this is easier to
achieve since some of the checking lives more naturally in the Web Service
protocol layer than the HTTP binding.

I don't see the need to prevent replay attacks in Web Browsing except in
the very special case of forms entry which servers can check themselves by
using a nonce passed in a hidden form field. I should probably add a
section to the draft explaining the reasoning there.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 22 Jul 2013 03:53:21 +0000

> without any actions or consent of the user. But not sure we can really

The hidden token field mechanism does its job, but it requires work and some inevitably get it wrong. Not necessarily as wrong as that firewall example ([1]), but still wrong. But I agree, that the more interesting concern is the privacy issue.

To be sure, changing the cookie-handling rules makes it so that the new session mechanism is not a drop-in replacement to session by cookies, and that means slow adoption, and that means that the old cookies live forever - you can't disable them. And yes, this is the kind of feature creep that made us wait 15 years to see any volume of IPv6 adoption. Still, it's something for the working group to consider.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Mon, 22 Jul 2013 03:56:48 +0000

Forgot the reference…

Yoav

[1] http://www.ietf.org/mail-archive/web/websec/current/msg01702.html

---

From: Trevor Perrin <[email-masked]>
Date: Mon, 22 Jul 2013 00:53:53 -0700

On Sun, Jul 21, 2013 at 6:13 PM, Phillip Hallam-Baker <[email-masked]> wrote:
[...]
> capability.

Yeah, scoping things to an Origin seems the best way to prevent one
domain from being able to force cookies/sessions for another domain.

[...]
> I don't see the need to prevent replay attacks in Web Browsing except in the
> very special case of forms entry which servers can check themselves by using
> a nonce passed in a hidden form field.

Well, it's possible to prevent a user from being able to replay a
different user's requests, as ChannelID shows.  In ChannelID, the
cookie is bound to the legitimate browser's public key, so can't be
replayed by a different browser.

This seems better than a mechanism that allows replay.

Trevor