Menu
I was wondered whether there is a survey or report of the current state of browser compliance with the three Cookie specifications: Netscape’s original draft, RFC 2109, and RFC 2965 that obsoletes RFC 2109.
I know that, due to its age, Netscape’s draft will be supported by most clients. But some recommend not to use it any more, e.g. this tutorial on Apache’s HttpClient:
Netscape draft: This specification conforms to the original draft specification published by Netscape Communications. It should be avoided unless absolutely necessary for compatibility with legacy code.
So what about the other specification? Are they ready to be used yet?
822
Cookies are set using the Set-Cookie header field, sent in an HTTP response from the web server. This header field instructs the web browser to store the cookie and send it back in future requests to the server (the browser will ignore this header field if it does not support cookies or has disabled cookies).
After receiving an HTTP request, a server can send one or more Set-Cookie headers with the response. The browser usually stores the cookie and sends it with requests made to the same server inside a Cookie HTTP header. You can specify an expiration date or time period after which the cookie shouldn't be sent.
The Set-Cookie HTTP response header is used to send a cookie from the server to the user agent, so that the user agent can send it back to the server later. To send multiple cookies, multiple Set-Cookie headers should be sent in the same response.
The consensus seems to be that they still aren't ready to be used yet. Some of the reasons for that are mentioned here and mostly relate to browser compliance.
However, on a hunch, I suspect your motive for asking this might relate to the session hijacking problem that has been brought into the limelight by applications like FireSheep.
If that's the case, I came across an interesting paper proposing a solution to the problem called OTC's—one-time cookies. It might be worth a read. It's title is One-Time Cookies: Preventing Session Hijacking Attacks with Disposable Credentials and it's from 4 PhD students at Georgia Tech.
(In case that google Docs link doesn't work here's a direct link to the PDF.)
In summary, it basically concludes:
While completely replacing HTTP with HTTPS will improve the overall security of the Web, it can be a challenging and complex project for some web applications . . . As a result, many web applications will remain vulnerable while site-wide HTTPS is being deployed, a process that is likely to take several years.
...
By relying on a well-known cryptographic construction such as hash chains, OTC creates disposable authentication tokens that cannot be reused, providing more robust session integrity . . . OTC is considerably more efficient than HTTPS and has approximately the same performance as current cookie-based mechanisms.
It's a very interesting read. I hope that helps someone in some way,
~gMale
98
The most recent survey out there seems to be the one written by Ka-Ping Yee in 2002, which is considered ancient in the evolution of WWW/Internet. The upside is that it surveyed 12 browsers across 3 OSs, which may give an fair insight about how they adapted cookie management.
Yee, Ka-Ping, "A survey of Cookie Management Functionality and Usability in Web browsers," http://zesty.ca/2002/priv/cookie-survey.pdf, 2002.
Another more recent article, although less relevant, is written by Yue, Xie, and Wang in 2009 (published in 2010). It conducted a large-scale study on HTTP cookie management with more than 5000 websites, using a system that can automatically validate the usefulness of cookies from a website and set the cookie usage permission on behalf of users.
Chuan Yue, Mengjun Xie, and Haining Wang, "An Automatic HTTP Cookie Management System," in Journal of Computer Networks (COMNET), 54(13) pp. 2182--2198, 2010.
34
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
