Cатсн²² (in)sесuяitу / ChrisJohnRiley

I like cookies…. which probably explains why none of my T-Shirts fit properly anymore. Still, HTTP cookies are good too, even if they don’t taste as good.

Michal Zalewski wrote a great piece discussing the ins/outs and general issues of cookies over on his blog (HTTP cookies, or how not to design protocols). In his blog he raised a number of issues and questions, and rightfully so. The cookie standard (depending on which RFC you go by) is seriously outdated and has been left behind by the constant march of progress.

Some of the issues he raises are already being examined and proposed solutions exist (at least in part) in the latest IETF httpstate cookie draft (at version 17 at time of writing).  I wrote a little about the IETF HTTP State Management Mechanism working group back in June. Trying to make sense of the mess that’s already been made is a difficult enough task without taking into consideration future uses (HTML 5 anybody!). Still they seem to be making headway in some areas.

In particular section 5.3 Storage Model includes (5) a section on rejecting public suffixes to, for example, prevent example.com.pl from setting a cookie for *.com.pl (an issue Michal talks about in his blog post). Having a blacklist might not be the most elegant solution here (after all the enforcement of this lies with the end users browser and how up-to-date their suffixes list is), however it’s a step into the right direction.

5.3 (10) also starts to make some inroads into the problem of non-HTTP sources (APIs) setting cookies with the HTTPonly flag set. It seems a little silly to set a cookie when you can’t read it… but nobody ever said the old RFCs made sense now did they! I can’t seem to see the same with the Secure flag, but I can also see possible scenarios where that could be acceptable to set.

I won’t bore you all by going on further, especially as I’m no cookie expert. If you’re interested in cookie (either the edible, or the HTTP kind) then checkout Michal’s blogpost on the subject and take a look at the IETF draft (it’s not as bad as you’d thing for an RFC draft).

I would also suggest interested parties to comment on the current draft if you see anything missing, or something that doesn’t solve an existing issue. After all, it’s only now that we can make our voices heard!

Links

• lcamtuf’s Blog –> HTTP cookies, or how not to design protocols
• lcamtuf Twitter –> http://twitter.com/#!/lcamtuf
• HTTPState Charter Page –> LINK
• Latest Draft –> LINK