为什么将iframe视为危险和安全风险？

124

为什么将iframe视为危险和安全风险？有人可以描述一个可以恶意使用的例子吗？

html  security  iframe 
— 丹尼尔T.
source
5
这听起来像是一个古老的妻子的故事。您的浏览器窗口基本上只是一个大iframe。
— 比尔·克里斯威尔
1
已经有人问过stackoverflow
— Samich 2011年
1
@Samich —不，那是关于最佳实践，而不是专门针对安全性问题（我能想到的唯一安全性问题是第三方使用iframe引起的）
— Quentin
安全性与其最佳实践不符，请访问：stackoverflow.com/questions/1081315/why-developers-hate-iframes 当人们也使用表设计div时，它们变得越来越流行，但除掉了iframe的需求。
— RandomUs1r 2014年
有趣的是，将近十年后出现了一篇文章，该文章建议将包含表单的任何内容放入iframe中，并与所有第三方javascript等隔离，这可能是保护表单不被获取的必要条件。 hackernoon.com/...
— GordonM

Answers:

83

当您显示来自另一个域的内容时，您基本上就是在信任该域不提供恶意软件。

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

— 狄更斯-詹姆斯·麦克法兰
source
19
一旦您链接到另一个域等的内容，……就没有关于iframe的特定信息。
— 昆汀
5
正确实施的浏览器（也称为用户代理）将不允许iframe内容泄漏到iframe之外。如果宿主文档（包含<iframe>元素的文档）具有适当的样式，并暗示iframe包含不受信任的内容，则没有问题。当然，浏览器中的模块化真实漏洞。简而言之，和<iframe>一样安全<a href>。
— Mikko Rantalainen
2
属于同一域的隐藏iframe呢？这完全安全吗？
— Ciaran Gallagher
2
<iframe>如果攻击者可以修改隐藏的iframe中的内容，则从同一域中隐藏该内容可能会导致安全风险。这将使攻击者可以将XSS攻击扩展到隐藏<iframe>在您站点上任何引用了<iframe>d内容的页面上的隐藏内容。有关详细信息，请参见stackoverflow.com/a/9428051/334451。
— Mikko Rantalainen 2014年
有趣的是，iFrame实际上可能是对付反向情况的有用保护。如果您的站点上有很多第三方脚本，则需要将表单与它们隔离。一种建议的实现方法是将表单放在没有第三方javascript的最小页面中，并将其显示在宿主页面的iframe中。 hackernoon.com/…–
— GordonM，
140

IFRAME如果您的站点嵌入IFRAME在恶意站点中，则该元素可能会带来安全风险。谷歌“点击劫持”获得更多细节。请注意，如果没关系，你使用<iframe>与否。免受此攻击的唯一真正方法是添加HTTP标头，X-Frame-Options: DENY并希望浏览器知道其工作。

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

那是问题的技术方面。另外，还有用户界面的问题。如果您让用户相信单击链接时URL栏应该不会发生变化（例如，您的网站使用包含所有实际内容的大iframe），那么将来无论在实际安全性方面，用户都不会注意到任何内容脆弱性。例如，您的网站中可能存在一个XSS漏洞，攻击者可以利用该漏洞从iframe中的恶意源加载内容。没有人能分辨出差异，因为URL栏看起来仍然与以前的行为相同（从未更改），并且内容“看起来”有效，即使该内容来自敌对的域要求用户提供凭据。

如果有人声称<iframe>在您的网站上使用某个元素是危险的，并且会带来安全风险，则他不知道该<iframe>元素的用途，或者他在谈论<iframe>浏览器中相关漏洞的可能性。<iframe src="...">标签的安全性等于<img src="..."或<a href="...">只要浏览器中没有漏洞。如果有合适的漏洞，有可能触发它即使不使用<iframe>，<img>或<a>元素，所以它不值得考虑这个问题。

但是，请注意<iframe>，默认情况下，的内容可以启动顶层导航。也就是说，<iframe>允许其中的内容自动打开当前页面位置上的链接（新位置将在地址栏中显示）。避免这种情况的唯一方法是添加sandbox没有值的属性allow-top-navigation。例如，<iframe sandbox="allow-forms allow-scripts" ...>。不幸的是，沙箱也总是禁用所有插件。例如，无法对YouTube内容进行沙箱处理，因为仍然需要Flash Player才能查看所有YouTube内容。没有浏览器支持同时使用插件和不允许顶层导航。

请注意，这X-Frame-Options: DENY也可以防止呈现性能的通道间攻击，该攻击可以读取跨源内容（也称为“ 像素完美定时攻击 ”）。

— 米科·兰塔莱宁（Mikko Rantalainen）
source
很好，但是不"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漏洞的（父）文档的方向上改写？
— 树正
@Shhengheng漏洞以两种方式同时存在，并且如果您<iframe>在页面上使用它，则可以将漏洞从iframe中的内容扩展到宿主文档。问题是<iframe>危险，如果宿主文档具有XSS漏洞，则实际上不需要此<iframe>元素。
— Mikko Rantalainen
13

我假设使用跨域iFrame，因为如果您自己控制它，则风险可能会更低。

  • 如果您的网站包含在iframe中，则点击劫持是一个问题
  • 遭到入侵的iFrame可能会显示恶意内容（想象一下，iFrame会显示登录框而不是广告）
  • 随附的iframe可以发出某些JS调用，例如警报和提示，这可能会惹恼您的用户
  • 包含的iframe可以通过location.href重定向（例如，想象一个3p帧将客户从bankofamerica.com重定向到bankofamerica.fake.com）
  • 3p框架（java / flash / activeX）中的恶意软件可能感染您的用户
— 乔·扎克
source
2

当人们提到iframe时，“危险”和“安全风险”并不是想到的第一件事……但是它们可以用于点击劫持攻击。

— 昆汀
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.