Re: [http-state] cake spec: server-side initiation only?

[Adam Barth <[e-mail]>]

On Fri, Dec 3, 2010 at 12:01 PM, Mike Wilson <[e-mail]> wrote:
> Reading http://www.ietf.org/id/draft-abarth-cake-00.txt,
> I wonder if client-side nonce generation (as initially
> proposed on the mailing list) was dropped altogether or
> just hasn't been speced yet?

Yeah, I haven't updated that document with my current thinking.  I've
been looking at a bunch of different variations in code.  Here's one
recent prototype:

http://codereview.chromium.org/4630001/

In case you're not familiar with Chrome's code base, the way this
works is as follows:

Set-Cookie: foo=bar; Origin

Using the Origin attribute sets the scope of the cookie to the current
origin (scheme, host, and port).  The Origin attribute overrides the
Domain and Path attributes.  Additionally, the cookie is returned to
the server in the Origin-Cookie header:

Origin-Cookie: foo=bar

The reason we return the cookie in a separate header is so the server
can know that the cookie was set by its own origin.  If we returned
the cookie in the Cookie header, then an attacker could inject a
non-Origin cookie with the same name and confuse the server.

On Fri, Dec 3, 2010 at 12:02 PM, Mike Wilson <[e-mail]> wrote:
> Earlier this year [1] we discussed state scoped on individual
> windows or tabs:
>
> [...]
>
> I see that you have addressed CSRF in cakes. Were/are you thinking
> that cakes is the better place to add future window scopes to?

Independently of the Origin attribute, I think an "instance" attribute
make sense.  Here we'd want to follow the same scoping rules as
sessionStorage (at the application layer).  In particular, each tab
has a separate scope, but if one tab is created from another, it
starts off with a clone of the previous tab's state.

These attributes are independent but combine nicely (as well as
combining nicely with the HttpOnly attribute).

Adam