Time for a new (HTTP) Cookie recipe?
Friday, August 4, 2006 5:17:23 PM
I've suggested two methods for dealing with the problem within the current cookie specifications, one using DNS lookups, which Opera is currently using, and the other requiring each TLD registry to post information about their domain structure.
Neither the TLD registries nor the DNS protocol people seem to want to use either of the proposals, basically because the proposals assigns "meaning to the content of labels and the position of labels" which they consider a mistake (apparently there are similar assumptions/problems in other proposals to the IETF, as well).
I certainly understand their reservations, but the abovementioned methods are the best I have been able to think of which that can control the existing problem without "breaking the Internet".
There is another option, however, which I considered mentioning as "Alternative 0" in my recent presentation of my proposals to the IETF DNS Operations Work Group, but it is a "break the Internet" proposal: Redefine how cookies are shared among servers, and disable the old versions, both Netscape and RFC 2965 cookies, in newer browsers (not necessarily at the same time).
So, how would a new cookie standard look?
For the most part I think it will look like the current RFC 2965 but with a few modifications:
- Remove the Domain attribute, and replace it with a SubDomain flag-attribute.
- Redefine the Path attribute so that the specified path must be a subpath of the default path of the URL setting the cookie.
- Add a $Origin attribute when sending cookies to the server, identifying the server setting the cookie
- Use the RFC 2965 request cookie attributes ($Domain, $Path) and $Origin for all cookies, also for Netscape cookies.
The current rules for the Domain cookie attribute are what have led to the problems I've described. The rules permit, with some restrictions, the server to specify any of its (grand)parent domains, implicitly assuming that the server's administrator is in control of that domain or permitted to send cookies to all servers in that domain. This is a dangerous assumption.
My suggestion is to remove the attribute completely, and only allow cookies to be set for one of two destinations: The server itself, or the subdomain (indicated by a Subdomain attribute) under the server, which has the same suffix as the name of the server. This means that server.example.com will be permitted to set cookies for itself, or to all servers x.server.example.com, but NOT to the domain example.com. This will restrict cookies to a domain where it is reasonable to assume the administrator has control, or is authorized to set cookies.
In a manner of speaking, this will make the server setting the cookie the main entrance of the site, with all content behind it.
The Path attribute has a similar interpretation as Domain: you can set a cookie for any parent path on your server (or domain), but not a subdirectory. Actually, the situation in Netscape cookies is a bit different, since Netscape never specifically said there was a path restriction when setting cookies, so the de-facto situation is that a server can set Netscape cookies (but not RFC 2965 cookies) for any path, without limitations. This is probably OK on a single-owner site, but not in shared hosting environment; The other website owners would not normally want to get somebody else's cookies.
My suggestion is that, if the abs-path of the URL setting the cookie is "/path/name", cookies should be limited to either the abs-path ("/path/name") portion of the URL setting the cookie, or to the default path ("/path/"), or to a path containg a prefix of "name" (e.g. "/path/na" or "/path/"+substring("name",x). As for domains, this will restrict cookies to an area of a website where it is reasonable to assume the administrator has control, or is authorized to set cookies.
When sending RFC 2965 cookies back to the server the client have to send along the Domain, Path and Port attributes that was used when the cookie was set. This was introduced to make the server able to distinguish which cookies it really wanted to use.
I suggest two changes to this format:
- This information should be sent with all cookies, also the old cookies, and the $Domain and $Path attributes should be sent even if they were not orginally defined (using the default values). This will make it possible for servers to verify that they are not getting cookies it should not receive.
- A $Origin attribute, specifying which server originally set the cookie. This attribute is not really necessary (and might perhaps be omitted) for cookies where the Subdomain attribute mentioned above is used, but will defintely be useful when handling
Netscape and RFC 2965 cookies. It could also help with debugging.
Another possibility I'm considering is whether or not there should be an upper limit for how long a cookie can be valid. There are lots of servers setting cookies valid for 10 to 30 years. Are such long-lived cookies really necessary? Should we put some restriction at one, two or five years, or some other number of years? At the very least, perhaps a new specification should make it clear that a client MAY enforce an upper time limit for how long a cookie can be valid.
I know many people, in particular Web designers, will react strongly to some, or all, of these proposals.
What I hope people will understand is that we have a potentially serious security and privacy problem within the current definition of how cookies are used, and that we should fix the problem.
Two of the possibilities are what I have proposed earlier, but those are, as a couple of commenters in the IETF DNSop Work Group put it, "kludges" and "hacks".
Another possibility is to make cookies safe (or safer) by default. That will, however, require a rewrite of the rules and deprecation of the old-style cookies, as suggested above.
Websites implemented according to the prposed definition above are, fortunately, compatible with the old system. During the transition to the new cookies, both types of cookies can be used.
What we need now are more suggestions for how to secure cookies. My suggestions are the best I have been able to think of. Perhaps somebody else can propose better solutions, with lesser impact on existing systems than my proposals?