Cookie Monster

HTTP Cookie Bug Affecting Servers On Most Non-Generic Domains

First posted 22 December 1998 NZDT (GMT+1300)

READ THIS: I am not tech support. Do not email me asking
for help with Yahoo!, My Netscape, or any other cookie-based services. Your
emails will be ignored!

Netscape claims on their bug report page (see below) that this
bug has been fixed since Navigator 4.51. This is untrue. The
bug has not been fixed, and there is no intention by Netscape/Mozilla
ever to fix this problem.
Therefore, Navigator version numbers will no longer be added to this
page. You can safely assume that any future Netscape browser (or Mozilla
derivative) does exhibit the bug. Please notify me only of Netscape
browsers that test not vulnerable on the demo below.

Internet Explorer 5 has tested on Win32 only and passed, but
we're yet to fully investigate its new handling of cookies.

Footnotes: (1) Netscape 4.x provides a preferences option "Accept
only cookies that get sent back to originating server." This option does
notappear 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 in my opinion. 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.

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.

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.

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. We have, however, seen examples of the
first case - sloppy programming.

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 very 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 hits,
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:

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.

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.

The links below (used to, but don't currently) 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 .edu.au.

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).

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.

Arun Stephens (aruns@ihug.co.nz)
also played a crucial part in the discovery of this security flaw and deserves
much credit. Arun is also a student from
Wellington, and is also available to provide Internet services such as web design.