As Netscape has not acknowledged my email or bug report from last week, and one form of this vulnerability is currently being used, I have decided it best to publicize this problem. SUMMARY This post describes a flaw verified in Netscape Communicator 4.6-0 as distributed by Red Hat software for x86 Linux and Communicator 4.51 and 4.61 for Windows NT. Communicator does not enforce "originating server" cookie restrictions as expected when JavaScript is enabled, leading to privacy issues for users who may think they have taken reasonable precautions. BACKGROUND Communicator 4.6 has a setting to warn before accepting cookies, and another to "Only accept cookies originating from the same server as the page being viewed". That latter option is supposed to, and used to, completely and quietly reject "DoubleClick" style third party ad cookies, i.e., cookies from servers that did not produce the main HTML document. These third party ad servers use cookies to track Web users as they move through completely unrelated Web sites. By accepting the cookie, one allows the third party to compile a profile of visits to other Web sites that use the third party's ad service (though normally the third party does not know the end user's exact identity). PROBLEM Last week I noticed a warning for a cookie (for doubleclick.net) not from the domain of the page I was viewing (newsalert.com) -- which the cookie settings should have rejected outright. If I turn off the warning, Netscape silently accepts the doubleclick cookie, although I still have the "originating server" restriction enabled. MEANS OF EXPLOIT The reason? I had JavaScript enabled for Web browsing. The offending newsalert page used a tag something like <SCRIPT language="JavaScript1.1" SRC="http://ad.doubleclick.net/..."> and Communicator seems to interpret this as a "page" from doubleclick when it's only getting a snippet of JavaScript code. INTENT ? I have been in communication with DoubleClick on this issue. They raise credible reasons to justify using <SCRIPT> instead of simple <A><IMG> tags: preventing caching, and allowing the ability to use media other than simple images for their ads. Nevertheless, this technique does subvert user preferences, regardless of whether this was the original intent. DoubleClick does have an "opt out" program that sets a generic cookie to prevent further tracking; see http://www.adchoices.com/ for details. Newsalert management and web staff have not responded. COMPETING PRODUCTS Initial tests with Microsoft Internet Explorer 5.0 for Windows NT suggest that it does not have any option like Netscape's "originating server" restriction. By explicitly categorizing *.doubleclick.net in a zone like "Restricted sites" where all cookies are disabled, MSIE 5 will reject cookies offered by doubleclick.net <SCRIPT> tags; of course this must be done for each third party domain individually. WORKAROUNDS Concerned Netscape users should either turn on warnings and read notices carefully, disable JavaScript, or completely disable cookies. SUGGESTED FIX The cookie security mechanism should not accept <SCRIPT SRC="..."> as a valid "page" for the purpose of the cookie settings. Nor should it allow any similar means of bypassing the "originating server" restriction, including external CSS files[1], or other documents not of type text/html. For each rendered page, the domain of the main document's URL should be compared against the domains of any other supplemental pieces in deciding if those pieces qualify as "originating server" content. VENDOR RESPONSE While there has been no response from Netscape Communications, I am grateful for the prompt, polite responses of DoubleClick's employees; although I disapprove of their willfully continuing to use this technique, and their advocacy of unwieldy "opt-out" procedures. -Peter [1] By specifying a style sheet from a different domain with <link rel="stylesheet" type="text/css" href="..."> you can also sneak a cookie past the "originating server" restriction, but only if both style sheets and javascript are enabled.[2] Even better, you can set cookies for more domains with "Location:" redirects. E.G. "http://example.org/" can have a URL like http://example.com/redirectPlusCookie in the LINK tag that issues a Set-Cookie and a Location header, redirecting the user to http://example.net/stylesheetPlusCookie. With JavaScript and CSS enabled, Netscape will accept cookies from both example.com and example.net. Or, a more vicious approach is to reference a URL on the same server which issues the redirect for the CSS or <SCRIPT> SRC to another domain. Users who look at the HTML source won't see anything unusual, but such redirections will also bypass the "originating server" setting. Finally, if you're not convinced of the problems, consider that these "originating server" tricks also work if you're viewing a file:// URL, even with a cookie-setting intermediate redirect. [2] Sorry, Netscape, I didn't tell you this last week because only now did I bother to test mechanisms other than the direct <SCRIPT> tag. The Intel Pentium III chip: designed to deny your privacy Boycott Intel. http://www.privacy.org/bigbrotherinside/
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:51:54 PDT