Home page logo

bugtraq logo Bugtraq mailing list archives

Communicator 4.[56]x, JavaScript used to bypass cookie settings
From: peterw () USA NET (Peter W)
Date: Fri, 9 Jul 1999 18:18:57 -0400

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.


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


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).


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.


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.


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.


Concerned Netscape users should either turn on warnings and read notices
carefully, disable JavaScript, or completely disable cookies.


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.


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.


[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/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]