Cookie Specification Vulnerabilities
Pages: 1, 2
Inserting a Cookie into HTML
Using Cookies Through the
Here's an example of setting a cookie with a
<META HTTP-EQUIV="Set-Cookie" CONTENT="John=Hacker; expires= Mon, 29-Dec-2003 03:00:00 GMT; path=/; domain=extrasy.net; secure">
As one sub-domain can only have 20 cookies, it's possible to exceed this limit if you have access to such a server. Upload the following HTML file on the server that the victim will use, such as the free email server described above.
<html><head> <META HTTP-EQUIV="Set-Cookie" CONTENT="John01=Hacker01; EXPIRES=Mon, 29-Dec-2004 03:03:03 GMT;"> <META HTTP-EQUIV="Set-Cookie" CONTENT="John02=Hacker02; EXPIRES= Mon, 29-Dec-2004 03:03:03 GMT;"> ... <META HTTP-EQUIV="Set-Cookie" CONTENT="John20=Hacker20; EXPIRES=Mon, Mon, 29-Dec-2004 03:03:03 GMT;"> </head></html>
Add at least 20 such records. Save this file as
will use it in other examples.
Another attack is to rewrite user cookies with empty or dummy data. This
exploits the cookies specification's limit of only 300 cookies. For this
attack, you need to register several sites on one of the numerous free hosting
providers' domain names, such as hack.site1.net, hack.site2.net, etc. Place on
each of them the above-mentioned
cook.htm. The following
index.html, uploaded to any free host, will attack the user and
force the removal of all host cookies:
<html><head></head> <frameset rows="0,0,0,0,0,0,0,0,0,0,0,0,0,0,*"> <frame scrolling="no" noresize target="hack.site1.net/cook.htm"> <frame scrolling="no" noresize target="hack.site2.net/cook.htm"> ... <frame scrolling="no" noresize target="hack.site15.net/cook.htm"> </frameset></html>
Another attack could force the user's browser to load and store a couple of megabytes of garbage cookie information. Depending on his connection, this could cause a disconnection.
<META HTTP-EQUIV="Set-Cookie" CONTENT="Data=You need to paste here 4kb of any trash data; EXPIRES= Mon, 29-Dec-2003 03:03:03 GMT;">
Cookie Status in Current Browsers
I would also like to provide a brief kick-test of the most popular browsers and the results of such cookie attacks. I've explored the browsers Internet Explorer, Netscape Communicator, Mozilla, and two console-only ones, Lynx and Links (which are mostly used on a Unix-running platforms).
The first attack produced expected results on all browsers. It is mostly not a technical attack, but a specification attack. However, it doesn't look to be very sensitive, as it will just render unavailable cookies for the specific domain. It could be fixed by disallowing cookies from non-authoritative sub-domains. Normally, it should not influence the work.
Moving forward, I've discovered that Netscape Communicator and Internet Explorer are not vulnerable to simple attacks, as described below. I did notice some strange cookie modifications by IE (in my tests it was Internet Explorer 5.00.2920.0000 with no Service Packs installed) during the attack of overloading the cookies cache with more then 300 cookies. Still, I suspect it's not vulnerable to such attacks.
As for text browsers Lynx and Links, I successfully attacked a cache of cookies using Lynx (2.8.4rel.1 from my sandbox) and Links (2.1pre11). From the other side, I can't say for sure that Lynx and Links are vulnerable browsers. Neither Lynx nor Links has a recently released version -- their releases are much like those I used for my tests. However, both of these browsers have development versions, and the results of attacks on the development versions differ greatly from the releases. I compromised the latest Lynx release version, which is 2.8.4, but the attack failed on the 2.8.5 dev 16, the latest available development version. I also failed to compromise Links browser links-2.1.pre14. This sounds like the developers are aware of security problems.
As for the Mozilla browser (Firebird from my sandbox) it also wasn't vulnerable, although it started swapping for about 30 to 60 seconds. I wasn't able to mention what changes have been made in the cache; everything kept working as it used to before the attacks.
To crown it all, I should say that the most modern and updated browsers are not vulnerable to simple cookie attacks, except for backdoors in the cookies specification. These are only fixable by good system-use policies.
Many of you may now say, "Oh, there is no need to worry about cookies now, my IE is not vulnerable!". But I've only performed tests for very, very simple cookie bugs. All these tests really indicate is that these browsers are pretty safe from kids' games, but not necessarily from professional attacks. If you refer to an archive of security papers devoted to cookies vulnerabilities of many versions of the different browsers, you won't feel so safe, although you will know better know what to protect yourself from.
Hopefully, a new cookie specification will soon emerge to provide the same useful service with more security. Until then, be careful.
Alexander Prohorenko is a certified professional, who holds Sun Certified System Administrator and Sun Certified Java Programmer certifications.
Return to the Security DevCenter.