Closed Bug 143985 Opened 22 years ago Closed 16 years ago

redirects can set third-party cookies despite pref setting (violates RFCs)

Categories

(Core :: Networking: Cookies, defect)

Product:
Core
Component:
Networking: Cookies
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: crispin, Unassigned)

References

(
URL
)

Details

(Whiteboard: [sg:want]) 

From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020502
BuildID:    1.0 RC2

If a third-party image is included in a page, then under certain curcumstances,
it can set cookies.

Specifically, if the (third-party) link is served by a redirect to the actual
image, with cookies being set as well, then the cookies will get set, against
the users wishes.

Note this bug allows people such as clickagents.com to set cookies against the
users wishes by having their actual adverts served through redirects.



Reproducible: Always
Steps to Reproduce:
1. Enable cookies for 'originating site' only
2. go to test url (and possibly reload)


Actual Results:  The cookie TEST=COOKIE for the site moonraker.ddts.net is set

Expected Results:  The test cookie should be ignored.

e.g. given the following page residing on mozilla-bug.flowerday.cx

<html>
<body>
<img src="http://moonraker.ddts.net/image.cgi">

</body>
</html>


The GET for http://moonraker.ddts.net/image.cgi returns something like the
following (only important lines showed):

HTTP/1.1 302 Moved Temporarily
Set-Cookie: TEST=COOKIE; path=/
Location: /red.gif

This cookie is being set even though it comes from a site that is not the
originating one.
Yes, what you are saying is absutely true, and is a well-known flaw in the idea 
of blocking third-party cookies.  The double-clicks of the world are aware of 
this and have been taking advantage of it for quite a while to set cookies in 
N4.x (and now in mozilla) in spite of the block-third-party-cookie pref being 
set.

The reason we need to consider a redirect as the original server is because a 
site could have a bona-fide reason for redirecting.  They have changed their 
server and are doing a redirect for people that access them through the old 
server.  In that case we would be breaking the site if we didn't consider the 
redirected location as the original server.

What you are stating in this bug report is something that I have been saying on 
my soap box for several years now.  Namely the whole idea of blocking 
third-party cookies is of no practical value.  I would have dropped it long ago 
from the product if it were not for the PR outcry that would result -- "Netscape 
no longer cares about users privacy!"

Therefore I would like to close this bug report out as wont-fix.  Not because I 
don't think there is a problem.  But rather because I don't think there is a 
solution -- whatever we do will either break legitimate sites or will have some 
other flaw that the doubleclicks will take advantage of.  Blocking third-party 
cookies is something that sounds like a good idea in theory but falls flat on 
its face when put into practice.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Both RFC 2109 (section 4.3.5) and RFC 2965 (section 3.3.6) explicitly mention redirects as an "unverifiable transaction" that should not be sent cookies. Following this spec might end up breaking legit uses of things like tinyurl, but it would also stop a lot of abuses.

Since we already violate the specs by not blocking 3rd party cookies by default there's no excuse not to take a stricter interpretation when users really do want 3rd party cookies blocked.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Summary: third-party cookies allowed when cookie option set to originating server only → redirects can set third-party cookies despite pref setting (violates RFCs)
Whiteboard: [sg:want]
Assignee: morse → nobody
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: tever → networking.cookies
Bitrot: http://mozilla-bug.flowerday.cx/cookie_bug.html is not currently working:
Resolving mozilla-bug.flowerday.cx... failed: Host not found.
Too bad Crispin Flowerday is not receiving bug mail.  
I put the HTML up at http://elvey.com/it/cookie_bug.html, but it still doesn't work because moonraker.ddts.net no longer resolves to a real IP:
host moonraker.ddts.net
moonraker.ddts.net has address 169.254.0.0

We could use a new example.

However,  The 4 Stanford authors of 
http://www2006.org/programme/files/xhtml/3536/index.html conclude: Unless the user is willing to disable all browser features that maintain long-term state, or frequently reset this state, no modern browser can offer meaningful privacy guarantees against cooperative attackers.

This seems to support what Morse is saying in Comment #1.
Thanks to chpe, I was pointed back at this bug as my test case wasn't working. I have updated the test case, and the good news is that the bug appears to be fixed from my reading of my original bug report - I'll leave it open for other people to check.
URL: http://mozilla-bug.flowerday.cx/cooki... → http://bugs.flowerday.cx/mozilla143985/
indeed, this bug is actually WFM with our current implementation (quite old now, but post-epoch relative to when this bug was filed!) - yay!
Status: NEW → RESOLVED
Closed: 22 years ago → 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.