Peter W posted to BUGTRAQ:
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.
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.
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
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.
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.
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, 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.
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.
 By specifying a style sheet from a different domain with
<link rel="stylesheet" type="text/css" href="...">
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.
 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
0 Talkback[s] (click to add your comment)