ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button
  Cookie Specification Vulnerabilities
Subject:   Full of errors
Date:   2004-04-06 02:17:44
From:   afindlay
There are just too many errors in this article for me to trust it. Some have already been mentioned by others, but here are a few more that can easily be checked by reading the Cookie Spec referred to in the article itself:

  • Cookie size limits: the specification requires 300 cookies of 4kb as the minimum limit that the browser may impose. Browsers are permitted to store more. Over-size cookies are trimmed from the end, not by removing the first bytes (doing that would corrupt the name of the cookie).

  • Cookies per server or domain: the limit is not '20 per second-level domain including sub-levels'. The specification actually says: '20 cookies per server or domain. (note that completely specified hosts and domains are treated as separate entities and have a 20 cookie limitation for each, not combined)'

  • The section on setting domain parameters implies that these only work in the generic top-level domains. Fortunately for non-Americans, this is not true. The specification actually requires domain values under .COM .EDU etc to have at least two dots where others are required to have at least three. This is still not ideal, but is much better than the situation presented in the article.

  • 'The path cannot be changed...' Wrong again: there would be no point in having the parameter if the application could not set it! There are things to be careful of though, e.g. path is tested using a leading-substring match, so path=/foo will match a URL pathname /foobar as well as /foo/baz

  • Cookie Attacks: the example attack code just redefines the cookie called John 20 times over. To set 20 cookies it would need to give each one a different name.

It is not exactly helpful to end up with 'Until then, be careful' without also giving people some idea of how to be careful! 'Good system use policies' are indeed a good thing, but in this case, what are they??

Andrew Findlay