The new vulnerability causes the following bug: a cookie that is set by a domain other than the American registrant (com, net, org, etc), Is erroneously allowed to be returned to servers on other domains. For example, a cookie set by the company.co.nz might be returned to all servers below the domain co.nz.
The following is a list of affected and unaffected Browsers.
Affected browsers:
Internet Explorer 5 Beta (Win32, NT5beta2), 4.x (Win32), 3.0x (Win32), 2.0 (NT).
Netscape Navigator 4.5 (Win32, MacOS, Linux, Sparc Solaris, FreeBSD), 4.0x (Win32, Linux, Digital Unix, FreeBSD, Irix, OS/2 Warp, MacOS), 3.0x (Win32, Linux, Digital Unix, Irix, MacOS), 2.0x (Win16, MacOS, OS/2) .
Opera 3.21, 3.51 (Win32)
NGLayout & Gecko (Win32)
NetPositive 2.01 (BeOS)
WebTV
IBrowse 1.22 (Amiga)
Unaffected browsers:
Lynx 2.8rel.2 (Linux): asks the user to "allow setting of cookie with invalid domain .co.nz"
Lynx 2.7: rejects invalid cookie.
OmniWeb (NeXTstep/Rhapsody): Andrew Aberrantly from OmniGroup reports that this browser is unaffected.
Netscape Communicator 4.x provides the option "Accept only cookies that get sent back to originating server". This option does not appear to affect whether Netscape Communicator 4.x is vulnerable or not.
There are several privacy, security, and efficiency implications resulting from this bug. These are detailed below:
1) Potential loss of private data
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 website where the information was entered is: (i) sloppy and sets the domain attribute to a second level domain, or (ii) is malicious, the personal information can be picked up by other servers. This second possibility is fairly academic, because if someone enters their details in a malicious site, that site could do what they want with the information anyway.
2) Wasted bandwidth
The cookie set to a second level non-US 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, and 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 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 pages, that's around 55KB - as more requests are made, traffic costs rise more than they need to.
3) Interference with other servers' scripts
The major implication of this bug is the potential for a website owner to interfere (willingly or accidentally) with another server's scripts. Cookies are generally used to customize a web site's behavior 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 web site's owner.
Examples might include:
1) 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.
2) A website uses information saved in cookies to personalize 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 display offensive material when viewed after visiting the malicious one.
