| Press Release | Latest Updates |
| Thank you very much to everyone who has contacted us with reports of browsers and platforms vulnerable. Special thanks do Daniel Austin for providing us with somewhere else to put the scripts! |
|
Vulnerable applications:
|
Unaffected applications:
|
If you find the working demonstration below successful on any browser, version, or operating system other than those listed above, email oliver@lineham.co.nz now. What about older versions of IE or Netscape? I can see no reason why the same browsers would not be susceptible on other operating systems. Yes, I know the list above is getting ridiculous.
| To find out what cookies actually are, and how they work try cookiecentral.com |
The bug: A cookie may be set by a server on a domain name other than the American TLDs (.com, .net, .org, etc.), which is erroneously allowed to be returned to servers on other domains. For example, company.co.nz may set a cookie in a user's browser that is returned to all servers below .co.nz.
This affects: Anyone using any of the browsers listed above (possibly more), who visit websites outside the US, or on the .us domain; Anyone operating a website or server on a non-US domain name or the .us domain.
Netscape 4.x provides a preferences option "Accept only cookies that get sent back to originating server." This option does not appear to work. At least, it doesn't stop this exploit working for me! This is another bug in Netscape.
Note: while some implications are similar, this cookie exploit is different to that recently announced by cookiecentral.com, involving placing three dots (...) after the domain name in a URL.
For reasons of security and privacy, a cookie set in a user's browser by a server should only ever be returned to trusted servers. That is, the same server that set the cookie, or another server in the same family. In fact, this restriction can be even tighter, specifying a particular path on a website that is only allowed to have the cookie returned. According to the
HTTP Cookies Specification written by Netscape, the restrictions on the domain attribute of a cookie are based on the number of dots in the domain address, and what the top-level-domain is:
"Only hosts within the specified domain can set a cookie for a domain and domains must have at least two (2) or three (3) periods in them to prevent domains of the form: ".com", ".edu", and "va.us". Any domain that fails [sic] within one of the seven special top level domains listed below only require two periods. Any other domain requires at least three. The seven special top level domains are: "COM", "EDU", "NET", "ORG", "GOV", "MIL", and "INT"."
Therefore, company.co.nz should not be able to set a cookie with a domain value of .co.nz, since nz is not an American TLD and .co.nz has only two (not three) dots. However this turns out not to be the case. The browsers listed above will accept the cookie as valid, save it to disk, and return it on each and every request to any other server on a .co.nz domain.
The browser appears to always accept a domain attribute with at least two dots, regardless of TLD. This means that:
This bug does not allow for the setting of a cookie to a domain that its writer is not on. For example, a.co.nz can set a cookie to the domain .co.nz, but not to .ac.nz.
There are several privacy, security, and efficiency implications resulting from this bug. These are detailed below.
People often enter personal details into forms on the web, and this information is sometimes saved as cookies in the user's browser. If the owner of the website where the information was entered is (i) sloppy and sets the domain attribute to a second level domain, or (ii) is malicious, such personal information might be picked up by a server on a domain other than the one where the user willingly provided their information. This second possibility is largely academic, as if someone enters their details into malicious site, that site could do what they want with the information anyway.
The cookie set to a second level non-US domain will be returned to all servers in that classification, in that country. That could count for a lot of data. For example, a web user might acquire a cookie set to the domain .co.nz. That cookie will be transmitted on each and every HTTP request that user makes when viewing commercial websites in New Zealand. The user's connection will be unnecessarily slowed, and the Internet will be carrying useless data.
Also, the wasted bandwidth also applies to servers as well - don't forget that people have to pay for incoming data too. A commonly used "SITESERVER" cookie carries about 50 bytes, and that adds up to a lot of money some times. On a web page with say 10 images, you're sending 550 bytes. After 100 pages, that's around 55KB - as more requests are made, traffic costs rise more than they need to.
The major implication of this bug is the potential for a website owner to willingly or accidentally interfere with another server's scripts. Cookies are generally used to customise a website's behaviour based on the cookie data received by the server. If a malicious website owner knows the variable name and values which operate another site's script, they might be able to force the other website to behave in a way other than that wanted by the user or the other website's owner.
Examples might include:
The links below provide a working demonstration of this exploit. This should work in all of the applications listed above, and will probably also in others. This example does nothing malicious and is safe to try.
Please note that while I did write the following scripts, I am not the owner of the websites on which they are hosted. Please do not contact anyone at www.law.uts.edu.au, or beta.austlii.edu.au, regarding the Cookie Monster exploit. (Thank you very much to Daniel Austin for hosting the scripts on those servers).
Step 1. Prove there are no relevant cookies set
Go to the showcookies page on the server www.law.uts.edu.au. No cookies will be passed from your browser to that server, so none will be listed on the resulting page.
Step 2. Set a cookie with a .edu.au domain
Go to the setcookie page on the server beta.austlii.edu.au. A cookie will be set in your browser, with the illegal domain restriction of .co.nz.
Step 3. Show that the cookie is returned to other .edu.au servers
Go back to the showcookies page on the server www.law.uts.edu.au (you may need to press Reload to get a fresh copy). The cookie set by the other website will be listed. This should not be possible according to the cookie specification.
Step 4. Remove the cookie
To avoid the wasted bandwidth described before, as a matter of housecleaning, and so that you can try the demonstration again, you should now go to the killcookie page to remove our demo cookie.
The source to the three scripts may be viewed here: setcookie.pl, showcookies.pl, killcookie.pl (except note that the domain for those cookies are now set to '.edu.au' in the live demonstration).
This and other vulnerabilities discovered with the way browsers handle cookies make it clear that cookies are not always safe.
However, it should be pointed out the the Netscape cookie specification itself has no major security issues with it. If implemented correctly, we have little to fear from cookies. The Cookie Monster vulnerability arises from the incorrect implementation of the cookie specification in the susceptible browsers. If the specification was implemented to the letter, this vulnerability would not exist. Cookies remain one of the most useful features of the web, without which many sites lose vital functionality. It is a shame that incorrect implementation dirties cookies with security concerns.
It has been pointed out to me that the whole idea of counting dots to determine valid domain settings for cookies is a fundamental flaw in the specification. It makes too many assumptions about what servers are trustable (not trust in the normal computing sense of the word). Its easily fixed though - only allow cookies to return to the server they came from, or only allow the domain setting of a cookie to be the same or lower level than the one it came from. That is, b.co.nz can set a cookie for a.b.co.nz, but not the other way around. That would solve everything.
This document is written by Oliver Lineham (oliver@lineham.co.nz), a student from Lower Hutt, Wellington, New Zealand. I also run a business offering Web Design and other Internet related services.
Arun Stephens (aruns@ihug.co.nz) also played a crucial part in the discovery of this security flaw and deserves much credit. Arun is a high school student also from Lower Hutt, and is also available to provide Internet services such as web design.
The contents of this page and the scripts it links to are Copyright © 1998. Permission is granted to reproduce small quantities of the page for purposes of fair review.
The authors of this page disclaim all responsibility for any damages or losses that occur as a result of the publication of this page and scripts.
Last
modified: 24 Dec 1998 23:08 NZDT (GMT+1300)