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

Because we're damned if we do, and we're damned if we don't!

Tag Archives: cookies

Cookies… the next generation

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!


    Draft IETF – HTTPState (Cookies)

    A friend of mine (thanks Ben) pointed me at the latest draft IETF covering HTTPState (i.e. Cookies). I’m sure there are lots of you who love reading RFCs in your spare time…. after all, we all suffer from insomnia at one point or another 😉

    Regardless, I found it interesting that the HTTPState Working Group are finally working to integrate the HTTPOnly flag into the RFC. The HTTPOnly flag was originally sugegsted in 2002 by Microsoft as a way to prevent what they saw as a common attack vector (i.e. Cross-Site Scripting being used to steal Session Cookies). Microsoft built support for the HTTPOnly flag into Internet Explorer 6 (sp1) and it was adopted by other major browsers and programming languages.

    The new working group are looking to replace the aging RFC2109 and the (supposed replacement) RFC2965 with a new standard based on the previous standards. Alone this wouldn’t be news, but alongside the update comes the integration of the HTTPOnly flag which, despite being widely used and supported for years, has never featured in the RFCs previously.

    The roadmap shows the working group aiming for March 2011 for a final release.

    Information from the “HTTP State Management Mechanism” Working Group

    Description of Working Group:

      The HTTP State Management Mechanism (aka Cookies) was originally
      created by Netscape Communications in their informal Netscape cookie
      specification (“cookie_spec.html”), from which formal specifications
      RFC 2109 and RFC 2965 evolved. The formal specifications, however,
      were never fully implemented in practice; RFC 2109, in addition to
      cookie_spec.html, more closely resemble real-world implementations
      than RFC 2965, even though RFC 2965 officially obsoletes the former.
      Compounding the problem are undocumented features (such as HTTPOnly),
      and varying behaviors among real-world implementations.

      The working group will create a new RFC that:
       * obsoletes RFC 2109,
       * updates RFC 2965 to the extent it overlaps or voids RFC 2109, and
       * specifies Cookies as they are actually used in existing
         implementations and deployments.

      Where commonalities exist in the most widely used implementations, the
      working group will specify the common behavior. Where differences exist
      among the most widely used implementations, the working group will
      document the variations and seek consensus to reduce variation by
      selecting among the most widely used variations.

      The working group must not introduce any new syntax or new semantics
      not already in common use.

      The working group’s specific deliverables are:
      * A standards-track document that is suitable to supersede RFC 2109
        (likely based on draft-abarth-cookie)
      * An informational document cataloguing the differences between major

      In doing so, the working group should consider:

      * cookie_spec.html – Netscape Cookie Specification



      * RFC 2109 – HTTP State Management Mechanism (Obsoleted by RFC 2965)
      * RFC 2964 – Use of HTTP State Management
      * RFC 2965 – HTTP State Management Mechanism (Obsoletes RFC 2109)
      * I-D – HTTP State Management Mechanism v2
      * I-D – Cookie-based HTTP Authentication
      * Widely Implemented – HTTPOnly
      * Browser Security Handbook – Cookies

      * HTTP Cookies: Standards, Privacy, and Politics by David M. Kristol