Subject: [http-state] Origin cookies

From: Adam Barth <[email-masked]>
Date: Sat, 5 Mar 2011 17:46:54 -0800

Hi http-state,

Now that we're done with phase 1, I've updated my phase 2 proposal:

http://www.ietf.org/id/draft-abarth-cake-01.txt

There's a bunch of boilerplate (and missing sections) in that
document.  The main idea is to provide a new cookie attribute that
lets server harmonize the security policy of their cookies with the
same-origin policy.  Harmonizing the two policies has a number of
general security benefits because security vulnerabilities often arise
when there's an impedance mismatch between security policies.
Specifically, origin cookies mitigate an important security hole in
cookies by preventing active network attackers from setting cookies
that overwrite the session identifies used by HTTPS web sites, e.g. as
described in Section 8.6 of draft-ietf-httpstate-cookie.

Let me know if you have any feedback.

Thanks!
Adam

----8<----

Abstract

   This document defines the Origin attribute for cookies, which lets
   servers harmonize the security policy of their cookies with the
   widely used same-origin policy.  Origin cookies provide both
   confidentiality and integrity, unlike the Secure attribute, which
   provides only confidentiality.

3.  Overview

   Using the Origin attribute, a server can set a cookie for its origin.
   Unlike the Path, Domain, and Secure attributes, the Origin attribute
   harmonizes the security properties of the cookie with the same-origin
   policy [cite: Principles of Origin].  In particular, the Origin
   attribute provides both confidentiality and integrity from other
   origins.

   The Origin attribute superceeds the Path, Domain, and Secure
   attributes.  The server can set these attributes as well to control
   the scope of cookies in legacy user agents.  User agents that support
   origin cookies will ignore these attributes when the Origin attribute
   is present.

   Origin cookies are returned from the user agent to the server in the
   Origin-Cookie header field and not the Cookie header field because
   the Cookie header field does not provide any information about the
   source of the cookie.  When the server receives a cookie in the
   Origin-Cookie header field, the server can reason that the cookie was
   set by its own origin, and not injected by another origin.

3.1.  Examples

   The server can set an origin cookie, which is returned in the Origin-
   Cookie header field.  Origin cookies support all the same attributes
   as other kinds of cookies, except Path, Domain, and Secure, which are
   ignored.

   == Server -> User Agent ==

   Set-Cookie: SID=31d4d96e407aad42; Origin

   == User Agent -> Server ==

   Origin-Cookie: SID=31d4d96e407aad42

   Non-origin cookies are returned in the Cookie header as usual.  If
   the user agent sends the server both origin and non-origin cookies,
   the origin cookies are returned in the Origin-Cookie header field and
   the non-origin cookies are returned in the Origin-Cookie header
   field.

   == Server -> User Agent ==

   Set-Cookie: SID=31d4d96e407aad42; Origin
   Set-Cookie: lang=en-US; Path=/; Domain=example.com

   == User Agent -> Server ==

   Cookie: lang=en-US
   Origin-Cookie: SID=31d4d96e407aad42

---->8----

---

From: "Remy Lebeau" <[email-masked]>
Date: Sun, 6 Mar 2011 03:00:13 +0000

Other than a typo near the end:

"... the non-origin cookies are returned in the Origin-Cookie header field."

I don't understand why a separate Origin-Cookie request header is needed.  It seems the Origin attribute of a cookie simply says the cookie can only be sent back to the URL it came from, while the Path/Domain/Secure attributes allow the cookie to be sent to any URL that satisfies the combo. So why add extra complexity of a new header? How does the server validate the legitimacy of the Origin-Cookie versus what it already validates for the Cookie header?

-----Original Message-----
From: Adam Barth <[email-masked]>
Sender: [email-masked]
Date: Sat, 5 Mar 2011 17:46:54 
To: http-state<[email-masked]>
Subject: [http-state] Origin cookies

Hi http-state,

Thanks!
Adam

----8<----

Abstract

3.  Overview

3.1.  Examples

   Cookie: lang=en-US

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

---

From: Adam Barth <[email-masked]>
Date: Sat, 5 Mar 2011 19:12:05 -0800

Consider a server at foo.example.com.  How can that server determine if a
cookie it receives was set by foo.example.com or by bar.example.com?
There's a similar problem with HTTP/HTTPS, which is what causes the
integrity problems with active network attackers.  The Origin-Cookie header
solves this problem by separating the cookies that were set by the same
origin from cookies that use the goofy old security policy.

Adam
 On Mar 5, 2011 7:01 PM, "Remy Lebeau" <[email-masked]> wrote:
> I don't understand why a separate Origin-Cookie request header is needed.
It seems the Origin attribute of a cookie simply says the cookie can only be
sent back to the URL it came from, while the Path/Domain/Secure attributes
allow the cookie to be sent to any URL that satisfies the combo. So why add
extra complexity of a new header? How does the server validate the
legitimacy of the Origin-Cookie versus what it already validates for the
Cookie header?

---

From: tho <[email-masked]>
Date: Mon, 7 Mar 2011 08:55:28 +0100

Hi Adam,

> http://www.ietf.org/id/draft-abarth-cake-01.txt

it's not clear how the stated confidentiality and integrity properties are achieved.

Could you please elaborate a bit about that ?

Thanks, t.

---

From: Adam Barth <[email-masked]>
Date: Mon, 7 Mar 2011 00:09:53 -0800

> Could you please elaborate a bit about that ?

Sure.  Let's assume we're dealing with an active network attacker, as
defined in Section 2 of this paper:

http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf

In particular, we've got an honest user (Alice) using a
standards-compliant web browser to visit an honest site (example.com)
that's entirely hosted over HTTPS, but the user is using an untrusted
network that's completely controlled by an attacker.

In this setting, the attacker controls all HTTP responses but only
HTTPS responses from host names owned by the attacker (for which the
attacker can purchase a certificate).  Also, in this model, the user
never agrees to whitelist certificate errors.

Confidentiality of Origin cookies is achieved the same way for Secure
cookies.  Namely, an Origin cookie set by https://example.com in
Alice's browser will only be sent over a TLS connection to
example.com.

Integrity of Origin cookies is achieved as follows.  Suppose the
example.com receives an Origin-Cookie header with a particular value
over a TLS connection.  If the header was sent by Alice's browser,
then the server can reason that the cookie was set by its own origin.
(Note: The same cannot be said of Secure cookies.)

Adam

---

From: tho <[email-masked]>
Date: Mon, 7 Mar 2011 18:50:40 +0100

Hi Adam,

> (Note: The same cannot be said of Secure cookies.)

If I understand correctly, the idea -- to be explicited in Section 5. -- is that the UA sends an Origin-Cookie header iff the referring doc URL matches the <scheme, host, port> tuple of the origin server to which the request is to be sent.  Right ?

Another question: it seems that the whole mechanism relies on HTTPS to guarantee the confidentiality and integrity (of origin) properties.  Right ?

t.

---

From: Adam Barth <[email-masked]>
Date: Mon, 7 Mar 2011 11:06:24 -0800

> If I understand correctly, the idea -- to be explicited in Section 5. -- is that the UA sends an Origin-Cookie header iff the referring doc URL matches the <scheme, host, port> tuple of the origin…

Cookies ignore the referring document.  The user agent decides which
cookies to include in a request based on the server it received the
cookies from and the server to which it is sending the request.

> Another question: it seems that the whole mechanism relies on HTTPS to guarantee the confidentiality and integrity (of origin) properties.  Right ?

The mechanism relies on the same-origin policy, which is what
everything else in the browser relies upon for security.

Adam

---

From: tho <[email-masked]>
Date: Mon, 7 Mar 2011 23:25:23 +0100

[I forgot to CC the list]

> cookies from and the server to which it is sending the request.

I still don't get it.  Could you please sketch the decision policy the UA uses to attach an Origin-Cookie on a request ?
Sorry to bother you, but the draft has holes which I need to fill in order to understand the whole chain.

t.

---

From: Adam Barth <[email-masked]>
Date: Mon, 7 Mar 2011 14:28:36 -0800

> Sorry to bother you, but the draft has holes which I need to fill in order to understand the whole chain.

Yeah, the draft is just an overview.

When the user agent receives a cookie with the Origin attribute, it
remembers the origin (in the sense of
http://tools.ietf.org/html/draft-ietf-websec-origin) of the HTTP
response that contained the cookie.

When sending an HTTP request to a URL, the user agent examines its
cookie store for any cookies with the Origin attribute that were
received from the same origin as that URL.  It then serializes those
cookies into the Origin-Cookie header and includes that header in the
HTTP request.

Adam

---

From: tho <[email-masked]>
Date: Tue, 8 Mar 2011 00:07:05 +0100

> cookies into the Origin-Cookie header and includes that header in the

Ok, now it's clear.

Thanks, t.