为啥 iframe 被认为是危险的和安全风险？

Posted 2023-02-16

【中文标题】为啥 iframe 被认为是危险的和安全风险？

【英文标题】：Why are iframes considered dangerous and a security risk?为什么 iframe 被认为是危险的和安全风险？

【发布时间】：2011-11-09 11:43:37

【问题描述】：

为什么 iframe 被视为危险和安全风险？谁能描述一个可以被恶意使用的例子？

【问题讨论】：

这听起来像是一个老妇人的故事。您的浏览器窗口基本上只是一个大 iframe。

*** 上已经是 asked

@Samich — 不，这是关于最佳实践，而不是具体的安全问题（我能想到的唯一安全问题来自使用 iframe 的第三方）

安全性不如它不被认为是最佳实践，请参阅：***.com/questions/1081315/why-developers-hate-iframes 当人们也使用表格设计时，它们更受欢迎，div 几乎消除了对 iframe 的需求。

有趣的是，近十年后出现了一篇文章，表明将包含表单的任何内容放入 iframe 中，与所有第三方 javascript 等隔离，可能有必要保护表单不被收集. hackernoon.com/…

【参考方案1】：

如果您的网站嵌入在恶意网站上的IFRAME 中，IFRAME 元素可能会带来安全风险。谷歌“点击劫持”了解更多详情。请注意，您 是否使用<iframe> 并不重要。对这种攻击唯一真正的保护是添加 HTTP 头 X-Frame-Options: DENY 并希望浏览器知道它的工作。

如果有人声称在您的网站上使用 <iframe> 元素是危险的并导致安全风险，他们不了解 <iframe> 元素的作用，或者他们在谈论浏览器中与 <iframe> 相关的漏洞的可能性。只要浏览器没有漏洞，<iframe src="..."> 标签的安全性就等于<img src="..." 或<a href="...">。如果有合适的漏洞，即使不使用<iframe>、<img>或<a>元素也可能触发它，所以这个问题不值得考虑。

此外，如果您网站上的任何页面包含可被利用的 XSS 漏洞，IFRAME 元素可能会带来安全风险。在这种情况下，攻击者可以将 XSS 攻击扩展到同一域内的任何页面，这些页面可以被说服加载到具有 XSS 漏洞的页面上的 <iframe> 内。这是因为来自<iframe> 内部同源（同域）的易受攻击的内容被允许访问父内容 DOM（实际上是在“宿主”文档中执行 JavaScript）。免受这种攻击的唯一真正保护方法是添加 HTTP 标头 X-Frame-Options: DENY 和/或始终正确编码所有用户提交的数据（也就是说，您的网站上永远不会出现 XSS 漏洞 - 说起来容易做起来难）。

但是，请注意，来自<iframe> 的内容默认会启动***导航。也就是说，<iframe> 中的内容被允许自动打开当前页面位置的链接（新位置将在地址栏中可见）。避免这种情况的唯一方法是添加没有值allow-top-navigation 的sandbox 属性。例如，<iframe sandbox="allow-forms allow-scripts" ...>。不幸的是，沙盒也总是禁用所有插件。例如，历史上 Youtube 不能被沙盒化，因为仍然需要 Flash 播放器才能查看所有 Youtube 内容。没有浏览器支持同时使用插件和禁止***导航。但是，除非您有一些非常特殊的原因，否则您不能相信 任何 插件在 2021 年完全适用于您的大多数用户，因此您可以始终使用 sandbox并保护您的网站免受用户生成内容的强制重定向。请注意，这将破坏尝试修改 document.top.location 的实施不佳的内容。沙盒 <iframe> 中的内容仍然可以在新选项卡中打开链接，因此实施良好的内容可以正常工作。另请注意，如果您使用<iframe sandbox="... allow-scripts allow-same-origin ..." src="blog:...">，则blob: 内容中的任何XSS 攻击都可以扩展到主机文档，因为blob: URLs always inherit the origin of their parent document。您不能将未经过滤的用户内容包装在 blob: 中并将其呈现为 <iframe>，就像您不能将该内容直接放在您自己的页面上一样。

示例攻击如下：假设用户可以使用 iframe 插入用户生成的内容；没有属性沙箱的<iframe> 可用于运行JS 代码document.top.location.href = ... 并强制重定向到另一个页面。如果该重定向转到执行良好的网络钓鱼站点并且您的用户不注意地址栏，则攻击者有一个很好的更改来让您的用户泄露他们的凭据。他们不能伪造地址栏，但他们可以强制重定向并控制用户之后可以看到的所有内容。将allow-top-navigation 排除在sandbox 属性值之外可以避免此问题。但是，由于历史原因，<iframe> 元素默认没有此限制，因此如果您的用户可以添加没有属性 sandbox 的<iframe> 元素，您将更容易受到网络钓鱼。

请注意，X-Frame-Options: DENY 还可以防止可以跨域读取内容的渲染性能侧通道攻击（也称为“Pixel perfect Timing Attacks”）。

这是问题的技术方面。 此外，还有用户界面的问题。如果您教导用户相信 URL 栏在他们点击链接时应该不会改变（例如，您的网站使用包含所有实际内容的大 iframe） ，那么用户将来也不会注意到任何实际的安全漏洞。例如，您的站点中可能存在 XSS 漏洞，该漏洞允许攻击者从您的 iframe 中的恶意源加载内容。没有人能分辨出其中的区别，因为 URL 栏看起来仍然与以前的行为相同（从不改变），并且内容“看起来”有效，即使它来自请求用户凭据的恶意域。

【讨论】：

很好，但不应该将 "This is because content from the same origin (same domain) is allowed to access the parent content DOM (practically execute JavaScript in the "host" document)." 改写为包含对 iframe 中（子）文档的 XSS 漏洞的（父）文档的方向？

@Shuzheng 该漏洞是双向的，如果您在页面上使用<iframe>，它允许将漏洞从 iframe 中的内容扩展到托管文档。问题是<iframe> 很危险，如果宿主文档有 XSS 漏洞，你真的不需要<iframe> 元素。

【参考方案2】：

一旦您显示来自另一个域的内容，您基本上就相信该域不会提供恶意软件。

iframe 本身没有任何问题。如果您控制 iframe 的内容，它们是绝对安全的。

【讨论】：

一旦您链接到来自另一个域等的内容……没有什么 iframe 特定于此。

正确实现的浏览器（又名用户代理）将不允许 iframe 内容泄漏到 iframe 之外。如果主文档（包含<iframe> 元素的文档）具有合适的样式并提示 iframe 包含不受信任的内容，则没有问题。模数浏览器中的真实漏洞，当然。简而言之，<iframe> 与<a href> 一样安全。

属于同一个域的隐藏 iframe 呢？这完全安全吗？

隐藏<iframe>来自同一个域，如果隐藏的iframe中的内容可以被攻击者修改，可能会导致安全风险。这将允许攻击者将隐藏的<iframe> 内的 XSS 攻击扩展到您网站上引用上述<iframe>d 内容的任何页面。详情请见***.com/a/9428051/334451。

有趣的是，iFrame 实际上可能是一种有用的保护，可以防止反向情况。如果您的网站上有很多第三方脚本，则需要将表单与它们隔离开来。一种建议的方法是将表单放在自己的最小页面中，没有第三方 javascript，并将其显示在主机页面的 iframe 中。 hackernoon.com/…

【参考方案3】：

我假设是跨域 iFrame，因为如果你自己控制它，大概风险会更低。

点击劫持

如果您的网站被包含为 iframe，则会出现问题 受损的 iFrame 可能会显示恶意内容（想象一下 iFrame 显示的是登录框而不是广告） 包含的 iframe 可以进行某些 JS 调用，例如警报和提示，这可能会惹恼您的用户 包含的 iframe 可以通过 location.href 重定向（哎呀，想象一下 3p 帧将客户从 bankofamerica.com 重定向到 bankofamerica.fake.com） 3p 帧 (java/flash/activeX) 中的恶意软件可能会感染您的用户

【讨论】：

你可以跨Flash的列表：P

【参考方案4】：

IFRAME 没问题；都市传说不是。

当您“使用 iframe”时，它不仅仅意味着一件事。这是一个词汇歧义。根据用例，“使用 iframe”可能意味着以下情况之一：

其他人在 iframe 中显示您的内容 您在 iframe 中显示 domeone else 的内容 您在 iframe 中显示自己的内容

那么，这些案例中的哪些会让您面临风险？

1.其他人显示您的内容

这种情况几乎总是被称为 clickjacking - 模仿您网站的行为，试图引诱您的用户使用虚假 UI 而不是真实网站。这里的误解是 您使用或不使用 iframe 无关紧要，这根本不是你的电话 - 这是 其他人使用 iframe，你无能为力。顺便说一句，即使他们并不特别需要它们：他们可以以任何其他方式复制您的网站、窃取您的 html、从头开始实施假网站等。

因此，放弃 iframe 以防止点击劫持 - 这完全是零意义。

2。您显示其他人的内容

在上述三篇中，这是唯一一篇有些冒险，但你一直阅读的大部分可怕文章都来自于same-origin policy 推出之前的世界。目前，仍然不建议将任何网站包含在您自己的网站中（谁知道明天会包含什么？），但如果它是可信赖的来源（accuweather、雅虎股票信息等），您可以放心地这样做。这里最大的禁忌是让用户（因此，恶意用户）控制 iframe 的src，告诉它要显示什么。 不要让用户将任意内容加载到您的页面中，这是万恶之源。但这是真的有或没有 iframe。这与他们无关；使用script 或style 标签可能会发生这种情况（祝你好运，没有它们） - 问题是你把它们放出来了。您网站上包含任何用户提供的内容的任何输出都是有风险的。如果不对其进行清理（去 HTML 化），您基本上是在为 XSS 攻击打开您的网站，任何人都可以在您的内容中插入 <script> 标签，这是个坏消息。比如，baaaad 新闻。

永远不要输出任何用户输入而不确保它是无害的。

因此，虽然 iframe 又是无辜的，但要点是：除非您信任来源，否则不要让它们显示第 3 方内容。换句话说，不要在您的网站中包含不受信任的内容。 （另外，不要跳到快速接近的货运列车前面。Duh。）

3.您在 iframe 中显示自己的内容

这个显然是无害的。您的页面是可信的，iframe 的内部内容是可信的，不会出错。 iframe 不是魔术。它只是一种封装技术，您绝对有权在沙箱中展示您的一段内容。这很像将它放在 div 或其他任何东西中，只是它会有自己的文档环境。

TL;DR

案例 1：不管你是否使用 iframe， 案例 2：不是 iframe 问题， 案例 3：绝对无害的案例。

请不要再相信都市传说了。事实上，iframe-s 是完全安全的。你也可以责怪script标签很危险；当恶意插入站点时，任何事情都可能导致麻烦。但是如何他们首先插入它？如果有人能够将 html 内容注入站点，则必须存在现有的后端漏洞。将一项技术归咎于常见攻击（而不是找到真正的原因）只是保持安全漏洞开放的同义词。找到火后面的龙。

未经处理的输出不好； iframe 不是。停止猎巫。

---

更新： 有一个属性叫sandbox，值得一试：https://www.w3schools.com/tags/att_sandbox.asp

更新 2： 在您对 iframe 发表评论之前 - 请考虑一下锤子。锤子很危险。它们看起来也不是很好，它们很难游泳，对牙齿有害，电影中的某个人曾经滥用锤子造成严重伤害。此外，只是用谷歌搜索它，大量文献说凡人甚至不能移动它们。如果这看起来是永远不再使用锤子的好理由，那么 iframe 可能不是你真正的敌人。很抱歉要越野。

【讨论】：

我不同意，在第 3 种情况下，将iframe 用于您自己的内容通常不是一个好主意。这是架构师解决方案不佳的标志。它可能会导致维护网站的所有问题，例如：如果您需要在 iframe 中包含全局样式/脚本怎么办？如何处理可用性问题（移动设备、屏幕阅读器...）？跨域严格限制可能会导致一些信任问题，因此我们不能假设在iframe 内部，一切都应该“正常工作”......

@Mr.DucNguyen 这些是假设，想象的坏例子和对可能根本不是问题的可能问题的不清楚的引用。我认为仅基于恐惧和感知到的“不良架构的迹象”而拒绝使用某种技术是非常糟糕的做法。使用 iframe 可能有非常正当的理由（是的，甚至是复数），是的，可以正确管理屏幕阅读器和便携式设备，这不是您是否使用 iframe 的问题。此外，“跨域严格限制”不应影响您自己的内容。因此，您的结论不成立。

感谢您的回复。我想你误会我了。我根本不会“拒绝”使用iframe。我同意你的 1 和 2，事实上，这些是 iframe 恕我直言的唯一“充分理由”。您应该知道子域也被认为是“跨域”（即www.abc.com 与abc.com 不同），如果您需要使用iframe 在您的网站树中包含某个其他子路径，那就是粗鲁设计的一大标志。只是我的 2 美分 :)

@Mr.DucNguyen 再说一次，我不认为这些是实际问题和/或不良设计的迹象，但是好的，正如你所说 - 你的 2 美分 :) 总是欢迎提出意见。跨度>

【参考方案5】：

“危险”和“安全风险”并不是人们提到 iframe 时首先想到的……但它们可以用于clickjacking 攻击。

【参考方案6】：

iframe 也容易受到跨框架脚本的攻击：

https://www.owasp.org/index.php/Cross_Frame_Scripting

【讨论】：

这些不是 iframe 特定的；你也可以说“脚本标签容易受到 XSS 攻击”，这些攻击首先需要一个现有的漏洞来利用。