Why can a child redirect a parent frame?

Question

I have a look at these two questions and i don't understand.

Redirect parent window from an iframe action

How to prevent IFRAME from redirecting top-level window

On one hand it appears that you can redirect the parent iframe and on the other you cannot? When i try it, I have no problem redirecting the parent frame so i'm curious as in why everyone say you cannot redirect parent frame unless you are on the same domain. But I can redirect without having the frame on the same domain.

As stated previously, will redirect the parent iframe. One thing to bear in mind is that both the website, and the site contained in the iframe need to be on the same domain for this to work, or you'll get an access denied exception.

Is it browser related?

Edit

I have two pages and this works but shouldn't :

On domain 1

<html>
  <body>
    <iframe src="http://domain2.fr"></iframe>
  </body>
</html>

On domain 2

<html>
  <body>
    <script type="text/javascript">
      window.top.location.href = "http://google.fr";
    </script>
  </body>
</html>

You CAN change the location of a parent frame. It's mostly used for financial pages, etc. to avoid any hack. — kpull1, Jul 31 '13 at 10:48
Yes i tested it and i can change it but why everywhere it's written that i can't change the location of the parent frame if it's not part of the same domain? — yokoloko, Jul 31 '13 at 20:20
@yokoloko You can't run scripts inside it or listen to when its location changed - but you can redirect it. — Benjamin Gruenbaum, Aug 02 '13 at 11:53
This actually is true, here's proof: http://jsfiddle.net/ppkzS/ ... It works in chrome without issue. — Parris, Aug 06 '13 at 06:13
Maybe have a look at [Frame buster buster buster …](http://stackoverflow.com/questions/958997/frame-buster-buster-buster-code-needed) — Bergi, Aug 06 '13 at 19:54

Elias Van Ootegem · Accepted Answer · 2013-08-09T11:52:46.150

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.

As a side note, many 3rd parties now add iframes via script tags and use postMessage to communicate with top. This gives encapsulation and provides a means for cross-site scripting. As a result, it doesn't even matter if ECMAScript removed window.top. The script listening to the iframe's messages can basically do anything it wants. — Parris, Aug 12 '13 at 22:32

score 6 · Answer 2 · answered Aug 06 '13 at 06:42

My guess is that it is the same reason you can do the following:

<a href="http://google.com" target="_top">Redirect top to Google</a>

I found the rules for this behavior here: http://www.w3.org/TR/html5/browsers.html#valid-browsing-context-name-or-keyword

I couldn't find a "why", but personally I have found it useful to redirect the parent after someone has clicked on something within an iframe. You may want to first perform an async operation and validate something before redirecting the entire page. Since this is already possible using the <a> tag perhaps it was found appropriate in JS as well. Not sure why the <a> tag allows the functionality though.

That being said you can always prevent this behavior by adding sandbox="" attribute, example: http://jsfiddle.net/ppkzS/1/

Oh thanks for the source, i guess you're right, it's the same behavior as "top" as stated in the document it should be able to redirect. — yokoloko, Aug 06 '13 at 08:47

score 5 · Answer 3 · answered Aug 06 '13 at 19:44

Whenever you use iframes, frames, or objects, you set up a hierarchy of windows, with these items acting as "window"s in this hierarchy.

You can traverse this hierarchy with properties such as .parent, .frameElement and the like. The property .top is the window at the highest point in the hierarchy and usually corresponds to the outermost frame.

Some actions are prohibited between windows in the hierarchy, others are not. Changing the location of a window is not prohibited.

Ultimately, people who say you cannot do this are incorrect. What you can't do is access the contents of one window from a different window if their domains differ. However, you can modify their location properties.

Nice and simple, thanks! I see that changing window.top.location does not violate the formal same-origin safety (in the worst case an ad frame can redirect top to a phishing site mimicking the original top). Your answer adjusts Ootegem's warning where he says "it's easy to redirect a client to a malicious site from within an iFrame, which is unsafe". — eel ghEEz, Jun 14 '16 at 03:03

score 0 · Answer 4 · answered Aug 02 '13 at 11:58

If you have two frames on the same domain (and also same protocol and port too), then one frame can redirect the other to wherever you want, and also access javascript properties, execute function from the other frame, etc.

Should you redirect one frame from the other to another domain (or protocol, or port), then you would lose the ability to do all that I previously stated due to the Same Origin Policy, but the redirect itself is allowed because, before the redirect, the two frames satisfied said policy.

Here is some useful information: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Same_origin_policy_for_JavaScript

Quoting from that page:

Two pages have the same origin if the protocol, port (if one is specified), and host are the same for both pages.

Obviously, frames is the same as pages.

I don't see why the redirect is allowed the two frames are never on the same domain and therefore don't satisfy the same origin policy. — yokoloko, Aug 03 '13 at 14:16

Why can a child redirect a parent frame?

4 Answers4

Linked

Related