96351 - accept cookies only from originating site easily circumvented

Status: RESOLVED DUPLICATE of bug 67447

(Core :: Networking: Cookies, defect)

Description

[Jeremy M. Dolan]

Set cookie permissions to "only accept from originating site". Go to URL.
Observe you now have a cookie from ".doubleclick.net".

Perhaps it's due to the IFRAME.

Comment 1

[Stephen P. Morse]

There are many ways to circumvent the originating-site-only cookies and 
doubleclick as learned how to do it.  The simplest way is to have the site do a 
redirect to doubleclick so double click can set the cookie as an originating 
site.

Without checking out this particular URL, I'm pretty sure that this is probably 
what they are doing (I have seen other sites that do it).  So unless you can 
show that there is some other problem here, I'm marking this as invalid.

Comment 2

[Jeremy M. Dolan]

"There are many ways to circumvent the originating-site-only cookies" because
this bug isn't fixed.

if (cookie domain) != (domain in URL bar) { don't accept }

IFRAMEs, redirects (for embeded content), javascript... it shouldn't matter.
Without this fix, the setting is fairly useless, it may as well be removed, or
everyone will just start using backdoors around it.

Comment 3

[Stephen P. Morse]

I respect your right to disagree, but I'm leaving this closed as invalid.  It is 
commonly agreed that if a site has moved and puts up a redirect at its original 
url, then the site you get to is still the original site.  Therefore we define 
the original site as the URL you clicked on or types in as well as any site that 
you get to via a redirect.

If you think that there are specific holes with javascript cookies by which a 
third-party site can fool the browser into setting an originating-site-only 
cookie, then find an example of that and open a new bug report for it.

Comment 4

[Jeremy M. Dolan]

> It is commonly agreed that if a site has moved and puts up a redirect at its
> original url, then the site you get to is still the original site.  Therefore
> we define the original site as the URL you clicked on or types in as well as
> any site that you get to via a redirect.

Yes, if the site I'm going to "has moved and puts up a redirect at its original
url", then everything still works fine. If it's an embeded image, or other
non-main-page item, then the cookie shouldn't be accepted. I *DARE* you to find
 a legitimate case where an image (or other embeded content) is on a differant
server then the main page, and that server has moved and put up a redirect, AND
that embeded content needs to set a cookie.

The only cases of all those occuring are global user tracking networks that are
purposly circumventing the bogus limitations of old browsers "only accept from
originating site" cookie setting.

Your last example of "if a site has moved and puts up a redirect" was flawed, as
that will still work (URL bar location changes), so reopening.

This is most certainly what users expect of the "only accept from originating
site" option. I don't know where "it is commonly agreed" that this should be
allowed.

Comment 5

[Stephen P. Morse]

The cookie is not accepted if an image or other embedded content does a 
redirect.  If you have examples to the contrary, then please post it here.  
Otherwise please stop reopening this bug report.

The case I was referring to is where when the main page itself does a redirect 
to doubleclick.  In that case the cookie is accepted because doubleclick is then 
considered as the originating server.

Comment 6

[Jeremy M. Dolan]

> The cookie is not accepted if an image or other embedded content does a 
> redirect.  If you have examples to the contrary, then please post it here.

Well, here's an example...

Clean profile, go to the URL.
Observe in cookies.txt we've accepted a cookie for domain doubleclick.net named
CheckForPermission.

Looking through network dumps, the GET that sets it is from:

<iframe
SRC="http://ad.uk.doubleclick.net/adi/theregister.co.uk/messagelabs;area=messagelabs;pos=1;sz=150x100;tile=1;ord=680845?"
width=150 height=100 marginwidth=0 marginheight=0 hspace=0 vspace=0
frameborder=0 scrolling=no>

When talking to that server to get that (NON ORIGINATING SITE) iframe, it sends
back:


HTTP/1.0 200 OK
Server: DCLK-AdSvr
Content-Type: text/html
Content-Length: 319
Set-Cookie: test_cookie=CheckForPermission; path=/; domain=.doubleclick.net;
expires=Sun, 26 Aug 2001 03:23:46 GMT
P3P: CP="CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR FIN INT DEM STA POL HEA PRE
COM NAV OTC NOI DSP COR"
Cache-Control: private, no-cache="Set-Cookie"
Date: Sun, 26 Aug 2001 03:08:46 GMT
Expires: Sun, 26 Aug 2001 03:13:46 GMT



This cookie is accepted. The image in the iframe is a local image (on
www.theregister.co.uk). It does not set a cookie. It's the IFRAME.

The next page I go to on the site has a similar IFRAME. The "CheckForPermission"
cookie is sent back:

Cookie: test_cookie=CheckForPermission

and then I'm sent my very own unique UID courtesy of doubleclick...thanks!

Set-Cookie: id=8000000c58f2094; path=/; domain=.doubleclick.net; expires=Tue, 31
Dec 2030 23:59:59 GMT

If that's not a case of "accept cookies only from originating site only" not
working at all, I don't know what is.



> The case I was referring to is where when the main page itself does a
> redirect to doubleclick.

I've never seen a main page redirect to doubleclick. I certainly hope you aren't
considering IFRAMEs to be main pages, now.

Comment 7

[Jeremy M. Dolan]

Over two week have passed since an example was posted. Reopening.

Comment 8

[Stephen P. Morse]

*** This bug has been marked as a duplicate of 67447 ***