The HTTP protocol is "disposable" in one sense. Each time the user requests a page, he begins all over again, no matter what he entered and which changes he made. There's no state to the protocol.
Cookies help to create the illusion that the site remembers a user. The user does not need to enter the same information from page to page or from session to session, because of the cookie stored on the user's disk. It is possible that the user can always edit or replace this information, too. A cookie can store various data -- for example, the quantity of page hits and their time. Cookies make it possible to create interesting web applications, such as a small organizer or a basket in virtual shop.
Many people dislike cookies because of their insecurity. However, many different analysts claim that there is no a problem, that it's absolutely impossible to make anything harmful with cookies. I deeply disagree: if someone can read the information from a cookie, it is already unsafe. I'll provide several theoretical examples that are easy to implement in reality.
Consider a web store at shop.provider.com. While making purchases in this shop, the site stores user information in a cookie. In parallel or before browsing the shop, the user browsed the attacker's page, hacker.provider.com, where malicious code could adjust the shop's cookie, changing the quantity of purchases, a name, the address, and anything else stored in the given cookie. It would be unpleasant to purchase unknowingly a few monitors for someone else, or to have your purchases sent to another user. This is a simple enough attack once you have a page in the second or third level of the shop's domain.
Let's dig deeper into the technical workings of cookies. For Windows users,
cookies live as multiple files in the folder
default in Internet Explorer) or as only one file,
you have Netscape Navigator or other browsers). Sites periodically add or
remove cookie information. Naturally, the cookie specifications stipulate some
elements of protection.
When the browser reaches 300 cookies, it should throw out the earliest cookies. If a cookie exceeds 4kb, the browser should cut out the first bytes.
Netscape maintains a full cookie specification. Describing it goes beyond this article, so I will include here only general information.
Cookies store information as
VARIABLE = VALUE pairs. One document can consist of a few cookies (less than 20). The absolute minimum cookie description is:
A fuller cookie description is:
Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME; secure
Here are the fields and their explanations.
NAME is the cookie's name and
VALUE is its value. You can change the
NAME as well as the
VALUE. The name cannot contain the space, carriage return, colon, or comma characters.
This is the date when the cookie will expire. You can change only
DATE. If expires is not set, the cookie will persist until the user closes her browser.
expires=Mon, 10-Apr-2002 03:00:00 GMT
The path cannot be changed; it stores the
PATH where cookie
will be sent. By default, if this field is not set, cookie will work only in
the current directory. If the path is
/, this cookie will affect
all directories on the server.
This sets the domain name where this cookie is active. It will also work for all sub-domains. This works only with COM, EDU, NET, ORG, GOV, MIL, and INT. It does not work in regional or other zones.
If this field exists, it means that this cookie will only work with HTTPS (HTTP with SSL). If it does not exist, HTTP is OK.
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;">
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.
Copyright © 2009 O'Reilly Media, Inc.