Closed
Bug 25857
Opened 26 years ago
Closed 26 years ago
a bug allows cookies to override the current domain restrictions enforced on the sharing of cookies.
Categories
(Core :: Networking: Cookies, defect, P3)
Core
Networking: Cookies
Tracking
()
VERIFIED
WONTFIX
People
(Reporter: Herve.Renault, Assigned: morse)
References
()
Details
this is an old story, but Mozilla M13 is vulnerable to this bug.
quoting http://www.cookiecentral.com/bug/index.shtml :
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.
Assignee | ||
Comment 1•26 years ago
|
||
This is old news. There was a lengthy discussion on this and related problems
in previous bugsplat and bugzilla bug reports; the bottom line was that the
problem was in the cookie spec itself and that no satisfactory solution in the
browser was possible (we tried several and found that they simply introduced new
problems.)
But this is not a security or privacy threat. Quoting from this bug report
itself:
"However, a malicious site could set a cookie containing sensitive
information that could be retrieved by any site."
I would change the word "malicious" above to "stupid." That site is not
stealing cookies from other sites but rather is exposing its own cookies to all
the other sites. That's the opposite of a privacy/security attack. At the very
worst, the site can do a denial-of-service attack by setting a huge number of
cookies which will get uploaded to innocent sites every time the user visits
those sites. But there's far worse things you can do with denial-of-service
attacks if that's your concern.
Therefore making this as wont-fix.
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → WONTFIX
Assignee | ||
Comment 2•26 years ago
|
||
If you want more info on the problem and why it can't be fixed, see bug 8743.
It goes into all the gory details.
You need to log in
before you can comment on or make changes to this bug.
Description
•