为什么孩子可以重定向父框架？答案

【问题标题】：Why can a child redirect a parent frame?为什么孩子可以重定向父框架？
【发布时间】：2015-02-15 08:08:05
【问题描述】：

这两个问题我看了看不懂。

Redirect parent window from an iframe action

How to prevent IFRAME from redirecting top-level window

一方面，您似乎可以重定向父 iframe，另一方面您不能？当我尝试它时，重定向父框架没有问题，所以我很好奇为什么每个人都说除非你在同一个域上，否则你不能重定向父框架。但是我可以在没有框架的情况下重定向到同一个域。

如前所述，将重定向父 iframe。要记住的一件事是，网站和 iframe 中包含的网站都需要在同一个域中才能正常工作，否则您将收到拒绝访问异常。

和浏览器有关吗？

编辑

我有两页，这可行，但不应该：

在域 1 上

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

在域 2 上

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

【问题讨论】：

您可以更改父框架的位置。它主要用于财务页面等，以避免任何黑客攻击。
是的，我测试了它，我可以更改它，但是为什么到处都写着如果父框架不属于同一个域，我就不能更改它的位置？
@yokoloko 您无法在其中运行脚本或收听其位置何时更改 - 但您可以重定向它。
这实际上是正确的，这是证据：jsfiddle.net/ppkzS ...它在 chrome 中运行没有问题。
也许看看Frame buster buster buster …

标签： javascript iframe

【解决方案1】：

如果您在同一个域上有两个框架（并且也有相同的协议和端口），那么一个框架可以将另一个框架重定向到您想要的任何地方，并且还可以访问 javascript 属性，从另一个框架执行函数等。

如果您将一个帧从另一个重定向到另一个域（或协议或端口），那么由于 同源策略，您将无法执行我之前所说的所有操作，但是重定向本身是允许的，因为在重定向之前，两个帧都满足了上述策略。

这里有一些有用的信息：https://developer.mozilla.org/en-US/docs/Web/JavaScript/Same_origin_policy_for_JavaScript

引用该页面：

如果协议、端口（如果一个是指定），并且主机对于两个页面都是相同的。

显然，frames 与 pages 相同。

【讨论】：

我不明白为什么允许重定向这两个框架永远不在同一个域上，因此不满足同源策略。

【解决方案2】：

我的猜测是您可以执行以下操作的原因相同：

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

我在这里找到了这种行为的规则：http://www.w3.org/TR/html5/browsers.html#valid-browsing-context-name-or-keyword

我找不到“为什么”，但我个人发现在有人单击 iframe 中的某些内容后重定向父级很有用。您可能希望在重定向整个页面之前先执行异步操作并验证某些内容。由于使用<a> 标签已经可以做到这一点，也许它在JS 中也很合适。不知道为什么 <a> 标签允许该功能。

话虽如此，您始终可以通过添加sandbox="" 属性来防止这种行为，例如：http://jsfiddle.net/ppkzS/1/

【讨论】：

哦，感谢来源，我想你是对的，它与文档中所述的“top”行为相同，它应该能够重定向。

【解决方案3】：

每当您使用iframes、frames 或objects 时，您都会设置一个窗口层次结构，这些项目在此层次结构中充当“窗口”。

您可以使用.parent、.frameElement 等属性遍历此层次结构。属性.top 是层次结构中最高点的窗口，通常对应于最外层的框架。

一些操作在层次结构中的窗口之间是被禁止的，其他的则不是。不禁止更改窗口的location。

归根结底，说你不能这样做的人是不正确的。您不能做的是，如果它们的域不同，则从另一个窗口访问一个窗口的内容。但是，您可以修改它们的位置属性。

【讨论】：

简单又好用，谢谢！我看到更改 window.top.location 不会违反正式的同源安全性（在最坏的情况下，广告框架可以将顶部重定向到模仿原始顶部的网络钓鱼站点）。您的回答调整了 Ootegem 的警告，他说“很容易将客户端从 iFrame 中重定向到恶意站点，这是不安全的”。

【解决方案4】：

为什么有可能的答案非常简单。 window.location 是 Web API 的一部分，它与 JavaScript 核心并不完全相同。它是DOM interface 的一部分，因此它由 W3C 而非 ECMA 管理。这就是为什么它允许您操作顶部窗口的属性。

严格来说，JS 无法做到这一点，因为它缺乏 IO 能力，这使得该语言具有极强的可移植性。这就是为什么浏览器实现需要 DOM API、查询 DOM、请求重绘或与客户端交互的原因。不过，DOM确实需要 IO，因为它会渲染并从实际 UI 中读取数据。由于 XSS 漏洞的原因，ECMAScript 委员会中的一些人宁愿看到对 window.top 的访问受到严格限制，如果不一起删除的话。遗憾的是，W3C 同意不同意，并实施了window.top 参考。
在这种情况下谁对谁错？我不知道，从 iFrame 中将客户端重定向到恶意站点很容易，这是不安全的。但是如果有一个 iFrame，然后无法访问顶部窗口，这将是令人沮丧的，这意味着无法轻松地与客户端进行交互。但这不是重点。底线是，您可以更改一些顶部窗口属性，它可能很有用。想想混搭。它们在 XSS 安全方面提出了很多挑战，但为 webaps 开辟了许多新的和令人兴奋的可能性。为了堵住一些最危险的 XSS 漏洞，take a look at ADSafe，它是由 Douglas Crockford 创建的。谷歌有一个类似的库，但我忘了它的名字 ATM...

同源政策也不适用于此处。通过更改浏览器窗口地址栏中的 url，您也将更改 window.top.location.href 属性。如果那里有同源限制，互联网就会死掉。你没有向另一个位置发送请求，你没有从第三方资源获取数据并将其加载到你的页面中，你正在将浏览器重定向到另一个位置，这会关闭并清除 DOM。

【讨论】：

附带说明，现在许多第 3 方通过脚本标签添加 iframe 并使用 postMessage 与顶部通信。这提供了封装并提供了一种跨站点脚本的方法。因此，ECMAScript 是否删除了 window.top 甚至都没有关系。监听 iframe 消息的脚本基本上可以为所欲为。