我有一个带有 iframe 的页面。该页面和 iframe 的源位于不同的域中。在 iframe 中，我使用了一个名为 CuteEditor 的富文本编辑器（事实证明它并不那么可爱）。 CuteEditor 中的某些 javascript 函数尝试访问“文档”，但浏览器拒绝访问，因为它们不在同一域中。
这是确切的错误：
访问属性“文档”的权限被拒绝
http://dd.byu.edu/plugins/cuteeditor_files/Scripts/Dialog /DialogHead.js
第 1 行
编辑 javascript 是不可能的，因为它已被缩小和混淆，因此所有变量名称都是神秘的。
目前不可能使用不同的编辑器，因为这是一个工作项目，而且这是我被告知要使用的编辑器。
有没有办法让 iframe 保持独立？那么它会在 iframe 内完成所有操作，并且不会尝试突破到父框架吗？
I've got a page with an iframe. The page and the source of the iframe are in different domains. Inside the iframe I'm using a rich text editor called CuteEditor (which has turned out to be not so cute). There are certain javascript functions in CuteEditor which try to access 'document' but the browser denies access since they're not in the same domain.
Here's the exact error:
Permission denied to access property 'document'
http://dd.byu.edu/plugins/cuteeditor_files/Scripts/Dialog/DialogHead.js
Line 1
Editing the javascript is out of the question because it's been minfied and obfuscated so all the variable names are cryptic.
Using a different editor is currently out of the question because this is a work project and this is the editor I've been told to use.
Is there a way to keep the iframe self-contained? So it does everything inside the iframe and doesn't try to break out to the parent frame?
发布评论
评论（2）
如果子 iframe 是从不同的域加载的，那么它将无法访问父页面或 DOM。
然而，仍然存在以下可能的中间人攻击漏洞。假设您的页面加载 http://yoursite.com 并且 iframe 转到 http://badsite.org
第一个 http://badsite.org 重定向到 http://yoursite.com/badpage
此步骤需要中间人攻击。攻击者必须能够介于用户和 yoursite.com 之间，或者控制 DNS 查找的答案。这比听起来更容易——任何对公共 WiFi 接入点拥有管理控制权的人都可以做到这一点（想想星巴克、酒店、机场）。目标是提供 http://yoursite.com/badpage 来自攻击者的站点，而不是您的实际站点。
然后，攻击者可以从（假）http://yoursite.org/badpage。因为它与主页位于同一域中，所以它将有权访问父 DOM。
HTML5 iframe 沙箱属性似乎是避免这种情况的方法。您可以阅读规范，但最好的描述可能是此处。
这似乎在 Chrome 上受支持，< a href="http://msdn.microsoft.com/en-us/hh563496.aspx" rel="noreferrer">IE10，FireFox、Safari。
该规范表示，如果未设置“allow-same-origin”属性，“内容将被视为来自唯一的来源”。这应该可以防止您的子 iframe 访问父级 DOM 的任何部分，无论浏览器认为 URL 是什么。
If the child iframe is loaded from a different domain, then it will not be able to access the parent page or DOM.
However, there is a still a possible vulnerability to man-in-the-middle attack as follows. Suppose your page loads off http://yoursite.com and the iframe goes to http://badsite.org
first http://badsite.org redirects to http://yoursite.com/badpage
This is the step that requires a man-in-the-middle attack. The attacker must either be able to get between the user and yoursite.com, or control the answers to your DNS lookup. This is easier than it sounds -- anyone who has administrative control over a public WiFi access point could do it (think Starbucks, hotels, airports.) The goal is to serve the content of http://yoursite.com/badpage from the attacker's site, not your actual site.
The attacker can then serve whatever malicious code they like from the (fake) http://yoursite.org/badpage. Because this is in the same domain as the main page, it will have access to the parent DOM.
The HTML5 iframe sandbox attribute seems to be the way to avoid this. You can read the spec, but the best description might be here.
This seems to be supported on Chrome, IE10, FireFox, Safari.
The spec says that if the "allow-same-origin" attribute is not set, "the content is treated as being from a unique origin." This should prevent your child iframe from accessing any part of the parent's DOM, no matter what the browser thinks the URL is.
您不必担心这种情况的发生。
iframe 跨源通信的唯一方法是使用 postMessage，并且只有当您直接侦听该域时才可能实现。
https://developer.mozilla.org/en/DOM/window.postMessage
You shouldn't need to worry about that happening.
The only way iframes can talk cross-origin is with postMessage, and that's only possible if you're listening to that domain directly.
https://developer.mozilla.org/en/DOM/window.postMessage