Cross server javascript used to circumvent cookies blocking




16 years ago
3 years ago


(Reporter: nico, Unassigned)


({privacy, sec-want})

privacy, sec-want

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [sg:want], URL)



16 years ago
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

  <script LANGUAGE="Javascript" 

... the protection is circunvented and a cookie from is accepted.
That script uses iframes, document.write, sorry but I can't figure the method
used. I've found ... 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
3. Visit
4. Go back to stored cookies dialog.

Actual Results:  
I got a cookie from

Expected Results:  
One of the following:
1) isn't allowed to load JavaScript code from
2) isn't allowed to set a cookie in the context of'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

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

Comment 2

16 years ago
hrmmm, yeah. should we dupe this to 180983?
confirming fwiw.

Ever confirmed: true
*** Bug 257716 has been marked as a duplicate of this bug. ***

Comment 5

14 years ago
Bug 149115 looks very similiar. There is a log for attached.

Comment 6

14 years ago
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, I'd be interested in hearing ideas on how
severe a problem this might be.
*** Bug 262656 has been marked as a duplicate of this bug. ***
*** Bug 264011 has been marked as a duplicate of this bug. ***

Comment 9

14 years ago
*** Bug 290256 has been marked as a duplicate of this bug. ***
Summary: Cross server javascript used to circunvent cookies blocking → Cross server javascript used to circumvent cookies blocking
*** Bug 299160 has been marked as a duplicate of this bug. ***

Comment 11

13 years ago
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

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

-> default owner
Assignee: darin → nobody

Comment 13

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

Comment 14

13 years ago
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.  
Duplicate of this bug: 228753
Whiteboard: [sg:want]
Duplicate of this bug: 354180
Keywords: privacy

Comment 17

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

Comment 18

11 years ago
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.
I will close his based on comment 18
Last Resolved: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.