Re: [http-state] Origin cookies and backwards compatibility

Adam Barth <ietf@adambarth.com> Thu, 07 April 2011 07:29 UTC

MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.02.1104070233430.4468@dr-wily.mit.edu>
References: <alpine.DEB.2.02.1104070233430.4468@dr-wily.mit.edu>
From: Adam Barth <ietf@adambarth.com>
Date: Thu, 07 Apr 2011 00:30:58 -0700
Message-ID: <BANLkTimhkQsoGrrgLKH3kju33GeWrz8j0g@mail.gmail.com>
To: Anders Kaseorg <andersk@mit.edu>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: http-state@ietf.org
Subject: Re: [http-state] Origin cookies and backwards compatibility
Precedence: list

On Thu, Apr 7, 2011 at 12:18 AM, Anders Kaseorg <andersk@mit.edu> wrote:
> draft-abarth-cake [1] seems to have a problem for servers that want to
> maintain compatibility with old clients (which I expect will be most of
> them, for a long while).  How can the server distinguish a client that
> does not support origin cookies from a client that supports them but does
> not currently have any to send?

Originally, my plan was that the server would set an Origin cookie.
The user agent would then return that cookie in the Origin-Cookie
header, which would inform the server that the user agent support
origin cookies.  However, it occurs to me now that there's an issue
with the Origin cookie getting evicted.

> If the server falls back on the plain Cookie header when Origin-Cookie is
> not present in the request, then an attacker can inject a plain cookie via
> several well-known methods [2], defeating the purpose of this proposal.

Assuming they're able to first evict the Origin cookie.

> It seems to me that a client supporting origin cookies ought to be
> required to notify the server if it is sending plain cookies but no origin
> cookies, so that the server has enough information to decide to ignore the
> plain Cookie header from sufficiently new clients.

Possibly.  There might be other solutions that don't involve spamming
every server with the information that the user agent supports Origin
cookies.  I'll think more about it.

> (By the way, there seems to be a typo here: “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.”)
>
> (By the way too, same-origin policies are typically defined using a
> (scheme, host, port) tuple [3], but draft-abarth-cake makes no mention of
> a port number restriction; is that intentional?  A port number restriction
> is important for shared virtual hosting environments, where it may be
> possible for one user to bind to the shared IP address on a high port
> number and steal cookies intended for another user on port 80.)

The draft is light on details, but the intention is that Origin
cookies are scoped to a specific origin, defined using the usual
(scheme, host, port) tuple.

Thanks!
Adam

Re: [http-state] Origin cookies and backwards com… Adam Barth