Cookie Monster HTTP Cookie Bug Affecting Servers On Most Non-Generic Domains First posted 22 December 1998 NZDT (GMT+1300) Happy New Year. Just under a year until bugs like this one become irrelevant. Special thanks do Daniel Austin for providing us with somewhere else to put the scripts! Oh, and happy holidays, if you're having them. Vulnerable applications: Unaffected applications: * Internet Explorer * HotJava 1.4.4 o 5 Beta (Win32, NT5beta2) * Lynx: (Linux, Irix, VAX/VMS, o 4.x (Win32, MacOS) Win95): o 3.0x (Win32) versions 2.7.x - 2.8, will o 2.0 (NT) either reject the invalid * Netscape Navigator1 cookie, or ask the user o 4.5 (Win32, MacOS, Linux, whether to accept it. Digital Unix, Sparc Solaris, * OmniWeb (NeXTstep/Rhapsody): FreeBSD, Irix, AIX) Andrew Abernathy from o 4.0x (Win32/NT4, Win16, OmniGroup reports that this MacOS, OS/2, Linux, Digital browser is unaffected. UNIX, FreeBSD, Irix, Sun * AWeb2 3.2 (Amiga) Sparc) o 3.0x (Win32/NT4, Win16, MacOS, Linux, Digital UNIX, Irix) o 2.0x (Win32, Win16, MacOS, OS/2) * Opera 3.21, 3.51 (Win32) * NGLayout & Gecko (Win32) * NetPositive 2.01 (BeOS) * Cyberdog 2.0 (MacOS) * WebTV * Arachne 1.41b (DOS, Linux) * IBrowse 1.22 (Amiga) * Voyager 2.95 (Amiga) * Browse 2.05 (Acorn) * Emacs-W3/4.0pre.35 * others extremely likely Footnotes: (1) Netscape 4.x provides a preferences option "Accept only cookies that get sent back to originating server." This option does not appear to work the way it sounds, and doesn't stop this exploit from working! This is either another bug in Netscape, or the feature is badly worded and in fact stops images or frames from setting cookies if they're not on the same server as specified in the Location box (which certainly shouldn't be possible anyhow). (2) AWeb 3.2 has two preferences - to enable cookies, and to enable RFC2109 compliance. When cookies are on, AWeb appears to be vulnerable unless RFC2109 compliance is also selected. What qualifies as "vulnerable"? If cookies can be switched off, that doesn't necessarily mean an application isn't vulnerable. If the demonstration below works when cookies are switched on, it's vulnerable. If the application simply does not support cookies at all, it won't make either list - it is simply irrelevant. If you test the working demonstration below 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. Contents * Summary Of Flaw * Detailed Explanation * Implications o Potential loss of private data o Wasted bandwidth o Interference with other servers' scripts * Are Cookies Safe? * Working Demonstration * Contacting Us * Legal Summary Of Flaw The bug: A cookie may be set by a server on a domain name other than the Generic 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-generic domain name. 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. Detailed Explanation 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: * Any country that operates subclassification of its domains is susceptible. For example, New Zealand (.nz), Australia (.au), United Kingdom (.uk), United States (.us), and Japan (.jp). * Generic domains such as .com are safe, as two dots means a domain such as .company.com must be specified. * Countries that do not subclassify their domains are not susceptible. For example, Switzerland (.ch), and Slovakia (.sk). 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. Implications There are several privacy, security, and efficiency implications resulting from this bug. These are detailed below. Potential loss of private data 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. Wasted bandwidth The cookie set to a second level non-generic 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. Interference with other servers' scripts 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: 1. Two British online retailers, A and B, are in competition. A sets a cookie that causes the cookie-based shopping-basket and ordering system to malfunction on B's site. Any web user who has previously been to A's site will find it impossible to order from B's in the future. This is achieved by setting a .co.uk cookie with the same name as one used by B.co.uk. 2. A website uses information saved in cookies to personalise pages for its visitors (using their name, city of origin, Esc). The malicious owner of another website sets second-level-domain cookies with the same names as those used, to make the first website to display offensive material when viewed after visiting the malicious one. Working Demonstration 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 Please take a second to remove the cookie to avoid the wasted bandwidth described before, as a matter of housecleaning, and so that you can try the demonstration again. 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). Are Cookies Safe? 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. Contacting Us 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. Legal 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: 4Jan 1999 20:12 NZDT (GMT+1300)