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