火狐 （在 Nightly 59.0a1 中修复）， 苹果浏览器（在 Safari 技术预览版 54 中修复）如果您请求图像并且服务器要求您使用 HTTP 基本身份验证进行身份验证，Edge 和 Internet Explorer 会显示身份验证对话框。这允许攻击者在用户的浏览器尝试加载图像时显示身份验证对话框：

• 火狐。从 Nightly 59.0a1 开始修复，但在最新的稳定版本中出现警告：

  

• 野生动物园。自 Safari Technology Preview 54 起已修复，但该模式仍存在于最新的稳定版本中。请注意，这是一个模态对话框，网站的其余部分显示为灰色。“您的登录信息将被安全发送”在技术上也是正确的，但可能会给粗心的用户留下错误的印象：

  

• IE11。本机 Windows 对话框锁定了整个浏览器：

  

如果你做realm一个很长的字符串a\ta\ta\t...a\t，IE11完全锁定。

精心挑选的域名和领域可以欺骗用户将他们的用户名和密码发送到攻击者的服务器，或者使您的网站完全无法访问。

正如Anders所说：Blender对身份验证对话框提出了很好的观点，而multithr3at3d对 on 属性的看法是正确的。a此外，Anders 添加了关于标签的争论，并且Matija有一个很好的链接来利用库进行渲染。

然而，还没有人谈论 SVG。

首先让我们假设所有输入和输出都经过适当的清理，因此不可能使用onerror/的技巧。onload而且我们对 CSRF 不感兴趣。我们在 XSS 之后。

首先担心<img src=的是它不遵循同源政策。但这可能没有听起来那么危险。

浏览器如何渲染 <img> 标签

< img src="http://domain/image.png" > 这是相当安全的，因为浏览器不会调用解析器（例如 XML 或 HTML 解析器），它知道会出现的是图像（gif、jpeg、png）。

浏览器将执行 HTTP 请求，它会简单地读取到达的 MIME（在Conetent-Type标头中，例如image/png）。如果答案没有Content-Type几个浏览器会根据扩展名进行猜测，但他们只会猜测图像 MIMEs:image/jpeg或image/png（image/giftiff、bmp 和 ppm 是可疑的，某些浏览器可能对猜测它们的支持有限）。一些浏览器甚至可能会尝试根据幻数猜测图像格式，但他们不会再尝试猜测深奥的格式。

如果浏览器可以匹配（可能猜到的）MIME，它会加载正确的渲染库，渲染库可能会溢出，但那是另一回事了。如果 MIME 与图像渲染库不匹配，则图像将被丢弃。如果渲染库调用失败，图像也会被丢弃。

浏览器永远不会接近执行（脚本）上下文。大多数浏览器只能从 javascript 解析器进入执行上下文，并且它们只能从application/javascriptMIME 或 XML 或 HTML 解析器访问 javascript 解析器（因为它们可能具有嵌入的脚本）。

要执行 XSS，我们需要一个执行上下文。进入 SVG。

使用 <img src="domain/blah/blah/tricky.svg" >

哎哟哎哟。SVG 是一种基于 XML 的矢量图形格式，因此它调用浏览器中的 XML 解析器。而且SVG有<script>标签！是的，您可以将 javascript 直接嵌入到 SVG 中。

这并不像一开始听起来那么危险。 支持标签内 SVG 的浏览器<img>不支持上下文内的脚本。理想情况下，您应该在浏览器支持脚本的地方使用 SVG<embed>或标签。<object>但是，不要为用户提供的内容这样做！

我认为允许 SVG 在里面<img src= 可能是危险的：

• XML 解析器用于解析 SVG，无论它是在<img>or<object>标记内。解析器肯定会使用一些参数进行调整，以忽略上下文<script>中的标签。<img>然而，这很丑陋，它在特定上下文中将标签列入黑名单。而且黑名单的安全性很差。

• <script>不是在 SVG 中实现执行上下文的唯一方法，SVG 中还存在onmouseover（和系列）事件。这又是一个棘手的黑名单。

• 过去，浏览器中的 XML 解析器确实遇到过问题，尤其是脚本块周围的 XML 注释。SVG 可能会出现类似的问题。

• SVG 完全支持 XML 命名空间。又是哎哟。 xlink:href在 SVG 中是一个完全有效的构造，并且 XML 解析器上下文中的浏览器可能会遵循它。

因此，是的，SVG 打开了几个可能的向量来实现执行上下文。而且，它是一种相对较新的技术，因此没有很好地硬化。看到关于 SVG 处理的 CVE 不会让我感到惊讶。例如ImageMagick 有 SVG 的问题。

<img src=http://evil.com问题不大，但<img src=a onerror=alert('XSS')>可以用来注入任意 JavaScript。事实上，任何结合任何“on”事件属性（例如 onerror、onclick、ontouchstart 等）的 HTML 标记都可以用于运行不受限制的 JavaScript 有效负载。

好的，这个怎么样：（你应该退后一步。）

<img src="file://uhoh.gif”>

哦，我知道，对吧？什么怪物！

好吧，如果您使用的是 SMB，则可能是...

这是一个已经存在 18 年的错误！请参阅1997 年的此漏洞报告。这是2015 年 BlackHat的相同漏洞。

这会影响 Internet Explorer，包括 Microsoft Edge。应该注意的是，这不会影响 Chrome 或 Mozilla 浏览器。IE 尝试自动验证攻击者的网站，将用户名和散列的 NTLM 密码传递给远程服务器，甚至通过互联网 (!!)。

因此，我得出结论，绝对没有人应该使用 IMG 标签。

是的，但它是 XSS 吗？不，我知道它不一定会发起或构成 XSS 攻击。虽然它可以从一个启动，但这不是必需的。跨网算不算？