为什么 iframes 被认为是危险和安全风险?有人能举个例子说明一下它可能被恶意使用的情况吗?
一旦您显示来自另一个域的内容,您基本上相信该域不会提供恶意软件。
Iframe 本身没有任何问题,如果你控制了 iframe 的内容,它们是完全安全的。
当人们提到 iframe 时,首先想到的不是“危险”和“安全风险”,而是它们可以用于 点击劫持攻击。
如果 你的网站嵌入了敌方网站的 IFRAME,则 IFRAME元素可能是一个安全风险。谷歌“点击劫持”获取更多细节。请注意,你是否使用 <iframe>并不重要。这种攻击的唯一真正保护是添加 HTTP 头 X-Frame-Options: DENY,并希望浏览器知道它的工作。
IFRAME
<iframe>
X-Frame-Options: DENY
如果有人声称在您的站点上使用 <iframe>元素是危险的并且会导致安全风险,他们不知道 <iframe>元素是做什么的,或者他们正在谈论浏览器中与 <iframe>相关的漏洞的可能性。只要浏览器中没有漏洞,<iframe src="...">标签的安全性等同于 <img src="..."或 <a href="...">。如果存在一个合适的漏洞,即使不使用 <iframe>、 <img>或 <a>元素,也可能触发它,因此这个问题不值得考虑。
<iframe src="...">
<img src="..."
<a href="...">
<img>
<a>
此外,IFRAME 元素可能是一个安全风险,如果任何页面在您的网站包含一个 XSS 漏洞,可以利用。在这种情况下,攻击者可以将 XSS 攻击扩展到同一域中的任何页面,这些页面可以被说服在带有 XSS 漏洞的页面上的 <iframe>中加载。这是因为来自 <iframe>内部相同来源(相同域)的脆弱内容被允许访问父内容 DOM (实际上是在“主机”文档中执行 JavaScript)。针对这种攻击的唯一真正的保护方法是添加 HTTP 头 X-Frame-Options: DENY和/或始终正确编码所有用户提交的数据(也就是说,永远不要在站点上出现 XSS 漏洞——说起来容易做起来难)。
然而,<iframe>3。也就是说,允许 <iframe>中的内容在当前页面位置上自动打开链接(新位置将在地址栏中可见)。避免这种情况的唯一方法是添加没有值 allow-top-navigation的 <iframe>4属性。例如,<iframe sandbox="allow-forms allow-scripts" ...>。不幸的是,沙箱也禁用所有的插件,总是。例如,在历史上 Youtube 不能沙箱,因为 Flash 播放器仍然需要查看所有 Youtube 内容。没有浏览器支持同时使用插件和禁止顶级导航。然而,除非你有一些非常特殊的原因,<iframe>5,所以你可以只是使用 sandbox总是和保护您的网站免受强制重定向从用户生成的内容,太。请注意,这将破坏试图修改 document.top.location的实现不佳的内容。沙盒 <iframe>中的内容仍然可以在新标签页中打开链接,所以实现良好的内容将工作得很好。还要注意,如果使用 <iframe sandbox="... allow-scripts allow-same-origin ..." src="blog:...">,则 blob:内容中的任何 XSS 攻击都可以扩展到主机文档,因为 <iframe>6。您不能在 blob:中包装未过滤的用户内容并将其呈现为 <iframe>,就像您不能将内容直接放在自己的页面上一样。
allow-top-navigation
<iframe sandbox="allow-forms allow-scripts" ...>
sandbox
document.top.location
<iframe sandbox="... allow-scripts allow-same-origin ..." src="blog:...">
blob:
示例攻击是这样的: 假设用户可以使用 iframe 插入用户生成的内容; 没有属性沙箱的 <iframe>可以用来运行 JS 代码(代码为 document.top.location.href = ...)并强制重定向到另一个页面。如果这个重定向发送到一个执行良好的钓鱼站点,而您的用户没有注意到地址栏,那么攻击者就有了一个很好的改变,可以让您的用户泄露他们的凭证。他们不能伪造地址栏,但他们可以强制重定向和控制所有内容,用户可以看到之后。将 allow-top-navigation排除在 sandbox属性值之外可以避免这个问题。但是,由于历史原因,<iframe>元素在默认情况下没有这个限制,所以如果您的用户可以添加没有属性 sandbox的 <iframe>元素,那么您将是 更容易受到网络钓鱼攻击。
document.top.location.href = ...
请注意,X-Frame-Options: DENY还可以防止可以跨原点读取内容的呈现性能侧信道攻击(也称为“ 像素完美定时攻击”)。
这是技术层面的问题。此外,还有用户界面的问题。如果你教你的用户相信网址栏在他们点击链接时不会改变(例如,你的网站使用了一个包含所有实际内容的大型 iframe) ,那么用户将来也不会注意到任何实际的安全漏洞。例如,您的站点中可能有一个 XSS 漏洞,允许攻击者从您的 iframe 中的敌对源加载内容。没有人能够分辨出其中的区别,因为 URL 栏看起来仍然与以前的行为相同(从未改变) ,而且内容“看起来”是有效的,即使它来自敌对域,正在请求用户凭据。
我假设跨域 iFrame,因为如果你自己控制它,风险可能会更低。
Iframe 也容易受到跨帧脚本的攻击:
当您“使用 iframe”时,它不仅仅意味着一件事。这是词汇歧义。根据用例的不同,“使用 iframe”可能意味着下列情况之一:
其他人在 iframe 中显示您的内容 您可以在 iframe 中显示其他用户的内容 您在 iframe 中显示自己的内容
1. 其他人显示你的内容
这种情况几乎总是被称为 点击劫持-模仿您的网站的行为,试图引诱您的用户使用假的用户界面,而不是真正的网站。这里的误解是,使用或不使用 iframe是不相关的,它只是不是你的呼叫-它是 其他人使用 iframe,你可以做什么。顺便说一句,即使他们并不特别需要它们: 他们可以以任何其他方式复制你的网站,窃取你的 html,从头开始实现一个假网站,等等。
所以,为了防止点击劫持而放弃 iframe 完全没有意义。
2. 显示别人的内容
在上面的三篇文章中,这是唯一的一篇是 有点冒险,但是大多数你一直在阅读的恐怖文章都来自于 同一原产地政策出现之前的世界。现在,仍然不推荐在你自己的网站中包含任何网站(谁知道明天它会包含什么?)但是,如果它是一个可信的来源(acuweather,雅虎股票信息等) ,你可以安全地做到这一点。这里最大的禁忌是让用户(因此,恶意用户)控制 iframe 的 src,告诉它显示什么。不要让用户将任意内容加载到页面中,那是万恶之源。但它是真实的 不管有没有 iframe。这与它们无关; 使用 script或 style标记可能会发生这种情况(祝你没有它们的生活好运)——问题是你让它们出去了。在您的网站上包含任何用户给定内容的任何输出都是冒险的。如果不对它进行消毒(反 HTML) ,你基本上就是在打开你的站点,让它遭受 XSS 攻击,任何人都可以在你的内容中插入 <script>标签,这是个坏消息。坏消息。
src
script
style
<script>
永远不要输出任何用户输入,而不确保它是无害的。
所以,尽管 iframe 是无辜的,但要点是: 不要让它们显示第三方内容,除非你信任源代码。换句话说,不要在网站中包含不可信的内容。(另外,不要跳到快速接近的货运列车前面。废话。)
3. 在 iframe 中显示自己的内容
这个显然是无害的。您的页面是可信的,iframe 的内部内容是可信的,不会有事的。Iframe 不是魔术; 它只是一种封装技术,您完全有权利在沙箱中显示内容的一部分。这很像将它放入 div 或其他内容中,只不过它有自己的文档环境。
请不要再相信都市传说了。事实上,iframe-s 是完全安全的。你也可以归咎于 script标签的危险性; 当恶意插入站点时,任何东西都可能导致麻烦。但是 怎么做是他们一开始植入的吗?如果有人能够将 html 内容注入到站点中,那么一定存在后端漏洞。将一种常见的攻击归咎于一种技术(而不是找到真正的原因)只是保持安全漏洞开放的同义词。找到火背后的恶龙。
iframe
未经过消毒的输出是不好的; iframe 不是。 停止政治迫害。
更新: 有一个属性叫做 沙盒,值得一查: < a href = “ https://www.w3school s.com/tag/att _ sandbox.asp”rel = “ norefrer”> https://www.w3schools.com/tags/att_sandbox.asp
更新2: 在你评论 iframe 之前-请想想锤子。锤子很危险。它们看起来也不漂亮,很难和它们一起游泳,对牙齿不好,电影里有个家伙曾经滥用锤子造成严重伤害。还有,刚刚谷歌了一下,很多文献说人类甚至不能移动它们。如果这看起来像一个很好的理由,永远不再使用锤子,iframe 可能不是你真正的敌人。对不起,我越轨了。