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

Question

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?

Solution 1

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.

Solution 2

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

Comments

[Pacerier]

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?

[Guffa]

@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.

[Pacerier]

Thanks for the clarification =) What are some known ways to bypass this restriction and get the url of the "container page" ?

[Guffa]

@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.

[daniel.sedlacek]

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???