What exactly can an IFrame do with the top.Location object (cross-domain)?

E

3

21

There is a very particular edge case in cross-domain policies regarding the window.top.Location object...

Let's say I have IFrame A , in domain www.bbb.com, living inside a page in domain www.aaa.com.

The page inside the IFrame can:

Compare window.top.location to window.location (to detect whether it's being framed)
Call window.top.location.replace(window.location) to redirect to self
Call window.top.location.replace("any arbitrary string") to redirect somewhere else

But it cannot:

Alert, Document.Write, or do any kind of output of window.top.location.href
Concatenate it in any other variable, or use it in any useful way
Call window.top.location.reload()

These are just the ones I could quickly find. I'm sure there are other edge cases.
It seems like the browser is not allowing the use of the top.location object if the top is in another domain, except for a few whitelisted things...

Is this documented anywhere?
Can I find what these whitelisted things are?
Is this in the HTML standard, and implemented equally in all browsers? Or is the implementation of this semi-random?

Emotionality answered 11/7, 2009 at 15:2 Comment(2)

if you do find an answer, especially to "is this documented anywhere", please do post it. I've had to work with IE cross domain security restrictions in the past, and it always seems to be learnt knowledge of what you can and can't do. I've never actually seen any documentation. – Absinthism 11/7, 2009 at 15:32

Definitely, but I haven't found anything so far (thus the question here) – Emotionality 11/7, 2009 at 17:0

I

6

The security rules does differ with the version of browser. Generally newer versions have stricter rules, but also more fine tuned.

I suspect that older browsers would freely let you access the location object of the top frame, a little newer browsers would deny it totally, and the current versions let you compare location objects but not read from them.

You might be able find documentation about this, but it would be specific for each browser and specific for each version of the browser. As far as I know, there is no real standard for this. Each browser vendor tries to protect the user as much as possible, while still keeping some usability for the web site builder. Generally you can't really assume that anything close to the border works in all browsers, or that it will continue to work in future versions.

Intelligibility answered 11/7, 2009 at 15:30 Comment(4)

What do you mean by "compare location objects but not read from them"? How could the embedded page compare its location without being able to know the top page's url? – Tinkling 3/7, 2012 at 15:2

@Pacerier: Because the location property is an object, that contains the URL of the page as the href property. You can compare the location objects even if they contain an URL from a different domain, but you can't read the href property from the location object when the URL is from a different domain. – Intelligibility 3/7, 2012 at 15:25

Thanks for the clarification =) What are some known ways to bypass this restriction and get the url of the "container page" ? – Tinkling 3/7, 2012 at 16:22

@Pacerier: Well, there is no reliable way to get around it, as it's a security restriction. If you would find a security hole that works in some browser, it's likely that it will be plugged in a future update. – Intelligibility 3/7, 2012 at 16:45

S

8

This is exactly specified by the HTML5 standard in section 5.5.3.1.

Sparge answered 3/10, 2013 at 17:18 Comment(1)

I wish the spec was more human readable. "with the following exceptions: The href setter, if the responsible browsing context specified by the entry settings object is familiar with the browsing context with which the Location object is associated" WHAT??? – Insupportable 4/3, 2016 at 15:10

I

6

The security rules does differ with the version of browser. Generally newer versions have stricter rules, but also more fine tuned.

I suspect that older browsers would freely let you access the location object of the top frame, a little newer browsers would deny it totally, and the current versions let you compare location objects but not read from them.

You might be able find documentation about this, but it would be specific for each browser and specific for each version of the browser. As far as I know, there is no real standard for this. Each browser vendor tries to protect the user as much as possible, while still keeping some usability for the web site builder. Generally you can't really assume that anything close to the border works in all browsers, or that it will continue to work in future versions.

Intelligibility answered 11/7, 2009 at 15:30 Comment(4)

What do you mean by "compare location objects but not read from them"? How could the embedded page compare its location without being able to know the top page's url? – Tinkling 3/7, 2012 at 15:2

@Pacerier: Because the location property is an object, that contains the URL of the page as the href property. You can compare the location objects even if they contain an URL from a different domain, but you can't read the href property from the location object when the URL is from a different domain. – Intelligibility 3/7, 2012 at 15:25

Thanks for the clarification =) What are some known ways to bypass this restriction and get the url of the "container page" ? – Tinkling 3/7, 2012 at 16:22

@Pacerier: Well, there is no reliable way to get around it, as it's a security restriction. If you would find a security hole that works in some browser, it's likely that it will be plugged in a future update. – Intelligibility 3/7, 2012 at 16:45

A

1

I have found about the only information an iframe in a different domain can get about window.top is document.referrer and even then, the URL retrieved has the document path and query string truncated. All you get is something like this: https://website.com

All other information attempts throw the cross-origin exception

Ainsley answered 20/1, 2023 at 17:45 Comment(0)

Recommended topics

Hot tags