Released : 14th December 98

We have confirmed a bug in the current implementation of the cookie protocol. The bug allows cookies to override the current domain restrictions enforced on the sharing of cookies. According to the Netscape specifications, cookies can only be set and read by the domain in which they are active, for instance Amazon.com can only read and set cookies within the Amazon.com domain. (note - for more information on cookies visit the main page)

The exploit allows a site to set cookies that can be shared between unrelated domains. The script overrides the domain restrictions by placing three '.' characters appended to the domain name. This confuses the browser about the top-level domain. To our knowledge, all the mainstream browsers are vulnerable to this exploit. Internet Explorer and Netscape are all known to be venerable on the Windows, Mac and Linux platforms.

Demonstrating this exploit, a domain name can set a cookie and then an unrelated domain can read it.

You can see this at work: -

Set the cookie from here:

http://www.cookiecentral.com.../cookie-exploit/set-cookie.cgi

Then retrieve it on another (unrelated) server like this:

http://www.project9.com.../cookie-exploit/get-cookie.cgi

Normally, the Project9.com domain would not have any access to cookies set from cookiecentral.com, however by confusing the browser using the three dots, this allows universal sharing of the cookie.

The current cookie protocol enforces a privacy model that restricts the interaction of cookies from different domains. By confusing the browser over the domain name, it does not know which domain to restrict the cookie to; therefore it is accessible through any domain. The problem is not within the protocol itself but the implementation of the specifications by the browser companies.

We believe this does not pose a major threat to the security of the information in your system stored within cookies, because cookies have to get set in a special way in order for the exploit to work. However, a malicious site could set a cookie containing sensitive information that could be retrieved by any site.

Recommendations

The major browser companies should carry out a review of their cookie implementation and make sure it fully conforms to the specifications laid down by Netscape. This should be done before there is any opportunity for more serious exploits to be discovered. Many sites make use of cookies to store various information. Cookies can hold valuable information about a user, such as names, credit card numbers and email addresses, they should be secure as possible. Cookies are only containers of information, they cannot "sniff" out data in themselves, but if a user agrees to give up information such as email address to web sites, they may very well store them in cookies.

Notes

- This only affects URLs using domain names, not IP numbers.

- To our knowledge, cookies set in an official manner cannot be read by the exploit.

- The cookie must be set in a special way for the exploit to work.

- When setting the cookie, the path attribute seems to be a mandatory piece of the header. Our example is set to path="/",

- We have also discovered that Internet Explorer does not store this type of cookie in a persistent state, probably because it can't store the domain value in the special user@domain format IE uses. However, it does store it a session cookie.

Latest Developments

24th Dec - Another bug called The Cookie Monster has been discovered, this bug is similar to the one demonstrated on this page, however this exploit affects servers on Non-US Domains. More information

14th Dec - The Microsoft Product Security Response Team has acknowledged our report and have passed the information onto their Internet Explorer development team, who will try to reproduce the bug.