158463 - Sites use iframes to bypass third-party cookie blocking

Status: RESOLVED FIXED

(Core :: Networking: Cookies, defect, P2)

Description

[Jerry Baker]

The NYTimes is using doubleclick ads in Iframes to bypass "cookies from
originating web site" prefs. Is there a way to prohibit cookies except from
originating web site even in the case of frames and IFrames?

Comment 1

[Wesha]

Reporter, please ALWAYS tell us your Mozilla's BuildID.

Possibly a dupe of bug 87388, bug 136135?

Comment 2

[Stephen P. Morse]

No, this is a losing battle.  Doubleclick et al learned a long time ago that 
they can easily get around this pref by doing a double redirect (puppies.com 
does a redirect to doubleclick with ?puppies.com in the query string, 
doubleclick is now first part and sets a cookie, then doubleclick redirects back 
to the site in the query string).  So plugging the iframe hole will just send 
nytimes to the redirect hole which is unpluggable.

Comment 3

[Wesha]

How come? I always thought blocking happens on the protocol level, not on page
rendering level... *shrugs*

Comment 4

[Mike Connor [:mconnor]]

based on morse's comments here, is this WONTFIX?

Comment 5

[Michiel van Leeuwen (email: mvl+moz@)]

No, i think this is valid.
Adding dependency to bug 187974

Comment 6

[Mike Connor [:mconnor]]

Thinking about this further, how would we ever be able to distinguish between
good and bad uses of iframes?  If you have an idea on this (not even code-wise,
just logic-wise) please speak up. :)

Comment 7

[thesh_bugs]

(In reply to comment #6)
> Thinking about this further, how would we ever be able to distinguish between
> good and bad uses of iframes?  If you have an idea on this (not even code-wise,
> just logic-wise) please speak up. :)

Well, the main thing would be to just look at the domains. If you are at
thissiter0x0rs.org and it has an iframe from thissitesux0rs.org, then you reject
the cookie. If they are both the same site, then you accept the cookie. What am
I missing?

Comment 8

[Chris Lawson (gone)]

(In reply to comment #7)
> (In reply to comment #6)
> > Thinking about this further, how would we ever be able to distinguish between
> > good and bad uses of iframes?  If you have an idea on this (not even code-wise,
> > just logic-wise) please speak up. :)
> 
> Well, the main thing would be to just look at the domains. If you are at
> thissiter0x0rs.org and it has an iframe from thissitesux0rs.org, then you reject
> the cookie. If they are both the same site, then you accept the cookie. What am
> I missing?

This was similar how I suggested to Simon Fraser that we might be able to fix bug 318574 within Camino itself, and he agreed with me (the discussion was on IRC, not in that bug). Basically, when we got the request to set the cookie, we should check to see if its domain matches the domain of the page we've got in the location bar, and if not, don't allow the cookie to be set (if third-party cookies are set to be rejected in prefs), and don't even show the sheet asking about it (since, IMO, "reject third-party cookies" takes precedence over "ask me about all cookies").

cl

Comment 9

[Jo Hermans]

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

Comment 10

[Chris Ilias [:cilias]]

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

Comment 11

[Jesse Ruderman]

I think we should at least have a pref for this, so paranoid users can have extra privacy/CSRF protection, and so we can find out how much of the Web would break if we made this the default.

Note that now that bug 324397 is fixed, third-party cookies for things other than iframes (e.g. images and scripts) are disabled by default.

Comment 12

[Mike Schroepfer]

Nice to have but I wouldn't block on this - moving to the wanted list...

Comment 13

[Mike Beltzner [:beltzner, not reading bugmail]]

FWIW, this is now standard behaviour on IE7 and Safari, putting us at a slight disadvantage when it comes to privacy, and a severe one when it comes to messaging about privacy.

Comment 14

[Mike Schroepfer]

Moving back to blocking list so we don't lose track..

Comment 15

[[e-mail]]

seems comical that this is assigned to morse, let's fix that.

Comment 16

[[e-mail]]

-> me, though i won't be able to look at this for at least a week.

Comment 17

[[e-mail]]

so, it turns out our current third party blocking feature takes care of this - see bug 417286 comment 14. we won't be doing this by default, though, because of the trouble it causes.

please reopen if there are specific circumstances relating to iframes where this feature fails.

Comment 18

[[e-mail]]

alas, i spoke too soon. our current code does correctly handle the first request pertaining to an iframe (when it's first constructed and loaded), but nsHttpChannel (and/or friends) doesn't set the originating URI properly for subsequent requests. (i discovered this using Mardak's neat testcase in bug 219157 comment 13.)

while we may be able to fix netwerk to handle this right, a more robust solution would be to have cookies start from the nsIChannel it's given, walk up the docshell tree to find the toplevel content window, and then grab the URI off that. this is similar to what we do for mailnews detection; see http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/extensions/cookie/nsCookiePermission.cpp&rev=1.21&mark=210-242#206). of course, doing this would require some interface abstraction/rejiggering, since netwerk can't depend on docshell. this interface problem is also somewhat related to bug 187974.

i have a dirty patch that kinda works, but the above problems need to be solved.

Comment 19

[[e-mail]]

fixed per bug 421494.