200716 - Cross server javascript used to circumvent cookies blocking

Status: RESOLVED FIXED

(Core :: Networking: Cookies, defect)

Description

[Nico]

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4a) Gecko/20030401
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4a) Gecko/20030401

It would be nice to also block JavaScript scripts coming from different servers.
Blocking images or cookies from different servers is a simple but useful way to
prevent user-tracking. 

But if you use something like this (from www.osnews.com):

  <script LANGUAGE="Javascript" 
   SRC="http://oz.valueclick.com/jsmaster">
  </SCRIPT>

... the protection is circunvented and a cookie from valueclick.com is accepted.
That script uses iframes, document.write, sorry but I can't figure the method
used. I've found http://bugzilla.mozilla.org/show_bug.cgi?id=39972 ... maybe
both bugs are related?.

That's all. Thank you very much for this great browser, nice piece of code :-)


Reproducible: Always

Steps to Reproduce:
1. Clean stored cookies and site configuration in
preferences->privacy&sec->cookies->manage stored cookies
2. Set "only accept cookies from the originating web site only in
preferences->privacy&sec->cookies
3. Visit www.osnews.com
4. Go back to stored cookies dialog.


Actual Results:  
I got a cookie from valueclick.com.

Expected Results:  
One of the following:
1) osnews.com isn't allowed to load JavaScript code from valueclick.com.
2) valueclick.com isn't allowed to set a cookie in the context of osnews.com's
page request. Even if frames or iframe are involved, "only from originating
server" cookies setting is defeated. 

Solution could be cutting in one of the above points or writting yet another
configuration dialog [accept, onlyfrom, whitelist, blacklist, never] for javascript.

Comment 1

[Darin Fisher]

i suspect this is a case where we aren't passing a nsIHttpChannel into the
cookie service's SetCookieString method.

Comment 2

[[e-mail]]

hrmmm, yeah. should we dupe this to 180983?

Comment 3

[Daniel Veditz [:dveditz]]

confirming fwiw.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

*** Bug 257716 has been marked as a duplicate of this bug. ***

Comment 5

[OstGote!]

Bug 149115 looks very similiar. There is a log for osnews.com attached.

Comment 6

[benc]

This is interesting. I've never been a big believer in parent domain-based
blocking, because the third party site could be entered as a subdomain (for
example, doubleclick.mozilla.org). I'd be interested in hearing ideas on how
severe a problem this might be.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

*** Bug 262656 has been marked as a duplicate of this bug. ***

Comment 8

[Phil Ringnalda (:philor)]

*** Bug 264011 has been marked as a duplicate of this bug. ***

Comment 9

[Kevin Brosnan]

*** Bug 290256 has been marked as a duplicate of this bug. ***

Comment 10

[Ed Lee :Mardak]

*** Bug 299160 has been marked as a duplicate of this bug. ***

Comment 11

[iik]

can we expect a fix from you darin?
i mean you work for google, right?
the advertising and tracking companies (including google) exploit this "cross server javascript feature" heavily...i bet this issue will probably never get fixed until those who pay you earn their money with this bug.

prove me wrong!

Comment 12

[Darin Fisher]

I'm all for implementing third-party cookie blocking properly in Firefox.

-> default owner

Comment 13

[David E. Ross]

*** Bug 330277 has been marked as a duplicate of this bug. ***

Comment 14

[David E. Ross]

If this bug cannot be readily fixed, then bug #257288 should be fixed to make locking cookie.txt as read-only a more effective (but partial) work-around.  

Re comment #12:  This is a core bug, not a Firefox bug.  Fixing this would not only fix it for Fireforx; it would also fix it for SeaMonkey once a new version of that uses the fixed Gecko core.  

Comment 17

[Jesse Ruderman]

dwitte, did you happen to fix this as part of bug 421494?

Comment 18

[[e-mail]]

yep, i'll bet a stack of pancakes that this is fixed. i don't have time to check, but if someone can verify that'd be great.

Comment 19

[Patrick McManus [:mcmanus]]

I will close his based on comment 18