Login/Register
why browsers allow setting cookie on the parent (cross) domain of an iframe?
Asked Answered
iframecookiesbrowserprivacyuser-tracking
P

1

16

Why can a site (a.com) having an iframe to another domain (b.com) have its cookie viewed and changed by that other domain document?

Just saw this happening in an Ad, and went to do a proof of concept, and it worked... here's what i did: first, pointed a.com and b.com to my test machine IP.

then i have: http://a.com/a.html (this would be the site where i saw the ad)

<html><body><script src="http://b.com/b.js"></script>

http://b.com/b.js (this would be the ad script inserted inline in the site, pointing to the advertiser company domain)

document.write('<iframe src="http://b.com/b.html"></iframe>');

in http://b.com/b.html:

<html><body><script>document.cookie = "test=1;domain=.a.com;path=/;expires=Tue, 30 Oct 2012 02:47:11 UTC";</script></body></html>

and after i run that, in firefox 14 stock, i have a cookie in a.com.

what governs that? where is this behavior defined?

Politicking answered 8/10, 2012 at 20:22 Comment(8)
This is indeed weird behavior. 5+ years later and no answer. Did you ever figure this out? – Membership
@machineyearning, have you really verified it. I did and I can't reproduce – Mantoman
I asked this question mostly to try to figure out the historical reasoning, and who much "lobby" on netscape/microsoft from advertising companies impacted it :) – Politicking
Good luck with the why. This kind of stuff never gets any answer around here. You will only get opportunistic bounty hunters, I know the feeling. – Ara
What if the browsers blocked the cookies set by third parties? clearly there is no values in blocking but a great value in allowing which in turn, exposes users to advertising that can be used as a source of revenue. The browser is just a medium for users to fetch, display and navigate information resources and not necessarily block the cookies. P3P is another standards they introduced but was not considered by many vendors due to the difficulty and lack of value. – Inferno
For the private applications iframing a set of services is a common practice, to provide a suite of services in which case allowing the cross domains to change the cookies on parent domain makes sense, if the browsers does not allow this it would be a problem? – Inferno
Can't reproduce it too. I guess that all tails are hidden nowadays, but what is a problem if b.js could just set cookie itself without an iframe? Directly via just document.cookie = "test=1;domain=.a.com;path=/;expires=Tue, 11 Jan 2032 02:47:11 UTC"; – Vu
@Vu good point. think that the same works if that code opens an iframe to c.com, then c.com code can also set cookies on a.com (i used b.js just to make it more similar to the ad space) – Politicking
V
1

In my opinion, it is due to the combination of CORS mechanism and by the fact that most browser allowing third party cookies by default.

You will find useful information on the developper Mozilla Cookies webpage:

While first-party cookies are sent only to the server setting them, a web page may contain images or other components stored on servers in other domains (like ad banners). Cookies that are sent through these third-party components are called third-party cookies and are mainly used for advertising and tracking across the web.

[...] Most browsers allow third-party cookies by default

To avoid this default settings, you will may be concerned by the SameSite cookies which:

let servers require that a cookie shouldn't be sent with cross-site requests

but

SameSite cookies are still experimental and not yet supported by all browsers.

Take also a look on CORS (Cross-Origin Resource Sharing) documentation, where you can read that:

The CORS mechanism supports secure cross-domain requests and data transfers between browsers and web servers. [...]

This cross-origin sharing standard is used to enable cross-site HTTP requests for:

[...]

  • Scripts (for unmuted exceptions).

You may also note in the developper Mozilla Security Same-Origin webpage that <frame> and <iframe> are ressources which may be embedded cross-origin

If you are concerned and would not accept any third-party cookie on Firefox, you may still install the Privacy Badger adds-on (made by the EFF), but this solution require access on the user browser.

Vasya answered 30/3, 2018 at 7:30 Comment(2)
I do not think CORS has anything to do with this. besides it being more recent than 3rd party cookie issue, 3rd party cookies do not require CORS headers on either requests to be allowed. it's simply there, by default. – Politicking
Not sure... please note that if the third party server would to set a cookie, it is required to add the "Access-Control-Allow-Origin" header in the server response. And assuming that "Access-Control-Allow-Origin" is a CORS (Cross-Origin Resource Sharing) header, finally in my opinion CORS has something to do with this. – Vasya

© 2022 - 2024 — McMap. All rights reserved.