Re: Harmonizing draft-west-cookie-prefixes-05 with the web origin concept

Hi Adam,

On Tue, Dec 22, 2015 at 09:12:01PM -0800, Adam Barth wrote:
> == Issues with draft-west-cookie-prefixes-05 ==
> 
> 1) As currently written, the __Secure- prefix is not as secure as the
> __Host- prefix because it supports the Domain attribute.  For example, if
> you wanted to recommend the most secure way to use cookies (including this
> feature), you'd recommend using __Host- rather than __Secure-.  In order
> for the names of the protocol elements to be self-describing, we should use
> __Secure- for the most secure option.
> 
> 2) Even with these extensions, there's still no way to use cookies in a way
> that matches the web origin concept.  Specifically, even if you use __Host-
> and set all the attribute correctly, your cookies are still shared between
> all the ports on a given host, which is different than web origins because
> web origins are determined by the scheme, host, and port.  Security
> problems commonly arise because these sorts of "cracks" between different
> security models.  For better security, there should be a way to use cookies
> with a security model that matches up with web origins.
> 
> == Proposal ==
> 
> I'm sure there will be endless bikeshedding about the syntax for cookie
> prefixes, but I'd like to make a proposal for a slightly different syntax
> (with different semantics) that addresses the issues I've raised above:
> 
> Set-Cookie: ['self']-SID=12345; Secure; Path=/
> Set-Cookie: [*.example.com]-SID=12345; Secure; Domain=example.com
> Set-Cookie: [*.example.com:*]-SID=12345; Secure; Domain=example.com
> Set-Cookie: [/foo/bar]-SID=12345; Secure; Path=/foo/bar
> 
> In this approach, the cookie prefix indicates the scope of the cookie:
> 
>  * In the first example, the prefix ['self']- restricts the scope of the
> cookie to the scheme, host, and port from which the cookie was set.
>  * In the second example, the cookie's scope is example.com and all of its
> subdomains, but restricted to the original port.
>  * In the third example, the scope is expanded to include all the ports.
>  * In the fourth example, the scope is the current scheme, host, and port
> as well as the path /foo/bar.
> 
> I've borrowed the syntax from CSP's source-list: <
> http://www.w3.org/TR/CSP2/#source-list-syntax>.  Specifically, the grammar
> for what goes inside the brackets would be roughly:
> 
> "'self'" / host-source / path-part
> 
> Obviously, we can continue to bikeshed the syntax, but this syntax also
> lets you use a short sequence when you want to match the web origin
> exactly: [/]-
> 
> More controversially, we might want to make these prefixes *authoritative*
> for the scope, meaning they would override any scope-related cookie
> attributes.  In the near term, we would still recommend that servers send
> the cookie attributes as well as the prefixes, but having the prefixes
> override the attributes gives us the flexibility in the future to
> depreciate the scoping attributes.

I'm seeing some interesting points raised above. I've also been bothered
in the past by the fact that the client couldn't send back the attributes
so that the server could check where the cookie came from, and your proposal
indeed addresses this.

Sure, the syntax will cause some discussion, especially for those who
need to lookup cookies indexed by name, or those who have to rename them
on reverse-proxies because the application server doesn't know the public
name/port. But that's just something to keep in mind for the discussion
and which must not divert the work.

However I'm seeing new difficulties which can arise from this method,
the first one being the non-unicity of the cookies sent to the server.
For example, a client could now send :

  Cookie: [*.example.com:*]-SID=12345; [/foo/bar]-SID=12346; ['self']-SID=12347; [*.example.com]-SID=12348; [*.example.com:*]-SID=12349; [/foo/bar]-SID=12350

and create confusion on the server side. Some implementations may grab one
instance, other ones may grab another one. And this will definitely happen
based on the crap we're seeing in field (eg: servers sending back set-cookie
that concatenate all learned cookies, etc).

Based on Mike's and your proposal, I'm wondering if a solution would not
be to use special name cookies in addition to the regular ones to pass
back *all* attributes and even to help define new attributes. We could
have something like this :

  Set-Cookie: __SID=12345; secure; path=/; domain=example.com;

  Cookie: __SID=12345; __attr_secure__SID=1; __attr_path__SID=/; __attr_domain__SID=example.com; __attr_origin__SID=https://example.com

etc... The idea being that "__attr_<attribute_name>" being prefixed in
front of the cookie name in requests so that the client can pass the
attributes it learned. This way, a cookie learned from the wrong
location (eg: injected from HTTP, JS or anything) could be detected
and replaced by the server. And it still provides unicity on the cookie
names and value in the request.

Just my two cents,
Willy

Received on Wednesday, 23 December 2015 05:48:54 UTC