9422 - Unsafe handling of illegal cookie domain attributes

Status: VERIFIED WONTFIX

(Core :: Networking: Cookies, defect, P3)

Description

[oliver]

OVERVIEW DESCRIPTION:

Mozilla accepts cookies set with certain 'domain' attributes that it should
not. This results in the cookie being returned to servers other than that which
set it.

STEPS TO REPRODUCE:

Visit the URL, there is a working demo and CGI code is posted. However here's a
really quick rundown of how to reproduce it.
1) use a server on a country domain (eg. "foo.com.xx")
2) set a cookie with a domain setting of only two levels (eg. ".com.xx")
3) use a server on a different domain (eg. "bar.com.xx") to verify the cookie
was accepted with an illegal domain attribute

ACTUAL RESULTS:

From *any* server on the Internet you can set a cookie with a domain attribute
of two levels or more. This is fine for generic TLDs (eg. foo.com, bar.net are
both safe) but causes a problem for others such as country domains (eg. .co.nz,
.com.au, are not safe).

EXPECTED RESULTS:

For security reasons Mozilla should at least be compliant with the various
cookie specs.
Netscape's HTTP Cookies Specification
http://www.netscape.com/newsref/std/cookie_spec.html
RFC2109 HTTP State Management Mechanism http://www.cis.ohio-
state.edu/htbin/rfc/rfc2109.html

BUILD/DATE/PLATFORM:

Tested nightly build 1999070708 Win32 on Windows 98
However, it is likely to affect all platforms.

ADDITIONAL:

The URL contains a very detailed explanation of the problem, and includes a
working demo (complete with CGI source code). Please excuse the page's hype ;)

Also note that this bug:
- was first detected in December '98, affecting most browsers (incl Opera, etc).
- also affects all versions of Internet Explorer prior to version 5
- also affects all releases of Netscape Navigator. Netscape has a KB article on
this bug (http://help.netscape.com/kb/client/981231-1.html) which implies the
bug was fixed in NN4.5x, which it was not. I have not yet tested NN4.6x.

General cookie-domain comments:
RFC2109 behaviour is preferable to the current behaviour. BUT even that
behaviour isn't great as it specifies a minimum number of .'s a domain must
have based on whether or not it is within a list of generic TLDs. This list is
hardcoded into the browser, and makes *no* provision for the future
introduction of more TLDs such as .web, .store etc.
After quickfixing Mozilla to comply with RFC2109 some thought should go into
the long term cookie-domain plan (I personally think cookies should only be
returnable to servers equal to or below the originating server. But thats not
in any spec I know of).

Comment 1

[Stephen P. Morse]

Yes, this is a particularly nasty problem.  We had investigated extensively when
it was first reported and came to the conclusion that there is no way for us to
fix it.  By going into conformance with the cookie spec we wind up breaking many
popular websites, notably yahoo mail.

For a detailed description of this and all the fixes we tried, see bug 8743.
Regretfully I have to mark this as "won't fix".

If this really is a problem for you, then use the stealth preference setting
that we introduced for people such as yourself.  This too is described in the
above-mentioned bug report.