Redirect Parent Window from an Iframe Action

Redirect parent window from an iframe action

window.top.location.href = "http://www.example.com"; 

Will redirect the top most parent Iframe.

window.parent.location.href = "http://www.example.com"; 

Will redirect the parent iframe.

How to force redirect in an iframe to open in parent window?

One solution might be to use target="_parent" element for the form inside iframe. Have a look at this answer. In such case you do not need to use JavaScript.

Redirect parent iFrame from nested iFrame

If you have access to the parent iframe's domain, you can simply redirect it using:

window.parent.location = 'http://new.location.com';

Small parent/top example

<Browser>
    <iframe1>
        <iframe2>
        </iframe2>
    </iframe1>
</Browser>

Inside iframe2 the following are true:

window.parent.parent == window.top // true
window.parent == window.top.frames[0] // true

Note: the following example presumes browser and iframe 1 & 2 all are from the same domain

Redirect the parent page from IFrame

It will be a hazard if we can manipulate other frames/window withou using client-side scripts or user-invoked actions.

Here's a list of alternatives:

Javascript options:

window.top.location.href=theLocation;
window.parent.location.href=theLocation;
window.top.location.replace(theLocation);

Non-javascript options:

<a href="theLocation" target="_top">Click here to continue</a>  
<a href="theLocation" target="_parent">Click here to continue</a>

Why can a child redirect a parent frame?

The answer to Why it is possible is perfectly simple. window.location is part of the Web API, which is not exactly the same as the JavaScript core. It's part of the DOM interface, hence it's gouverned by W3C, not ECMA. That's why it allows you to manipulate the top-window's properties.

Strictly speaking, JS isn't capable of doing this, because it lacks IO capabilities, which makes the language extremely portable. That's why browser implementations require the DOM API, to query the DOM, and request repaints or interact with the client. The DOM, though, does need IO, because it renders, and reads from the actual UI. Some people in the ECMAScript committee would rather have seen the access to the window.top heavily restricted, if not removed all together, for XSS vulnerability reasons. Sadly W3C agreed to disagree, and implemented the window.top reference anyway.

Who's right or wrong in this case? I don't know, it's easy to redirect a client to a malicious site from within an iFrame, which is unsafe. But it would be frustrating to have an iFrame, and then not having access to the top window, which would mean not being able to interact with the client as easily. But that's not the point here. Bottom line is, you can change some top window properties, and it can be useful. Just think about mashups. They pose a lot of challenges in terms of XSS safety, but open up a lot of new and exciting possibilities for webaps. To plug some of the most dangerous XSS vulnerabilities, take a look at ADSafe, which was created by Douglas Crockford. Google has a similar lib, but I forgot its name ATM...

the Same origin policy doesn't apply here, either. By changing the url in the address bar in your browser window, you're changing the window.top.location.href property, too. If there were same-origin restrictions there, the internet would be dead. You're not sending a request to another location, you're not getting data from a third-party resource and loading it in your page, you're redirecting the browser to another location, which closes and clears the DOM.

---

Related Topics