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)

defect

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.
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
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.
verified WONTFIX
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.