曾经有一个“漏洞”，图像可以发送HTTP 401 Unauthenticated响应，这将触发用户的登录屏幕。如果您将此设置为论坛头像，它将为访问您头像所在页面的任何人生成一个登录弹出窗口。然后很多人会尝试使用一些用户名和密码组合登录，可能是他们论坛帐户的组合。

我的一个朋友几年前发现了这个，但现在它似乎不再起作用了。至少几个月前我不能轻易地复制它。编辑：我错了，这种攻击还是有可能的！/编辑

至于这种方式的XSS攻击，你是安全的。浏览器将或应该始终将其解释为图像，无论它包含什么或发送什么标头。您可以根据请求自定义图像（将小图像提供给论坛软件，预先检查图像，使其不会缩小图像，然后对其他人来说很大）。或者向浏览器提供大量 gif 数据，直到内存耗尽或其他情况。但据我所知，这里没有真正的大漏洞允许远程代码执行。

CSRF 攻击对你来说只是适度安全的。图像可以发出HTTP 302 Moved Temporarily响应并链接到新位置。例如，它可以链接到，我不记得具体的 URL，比如https://accounts.google.com/logout让你退出谷歌（这在几个月前有效）。或者，稍微更恶意：http://example.com/guestbook.php?action=post&message=spam-url.example.com.

据我所知，只有 GET 请求可以通过这种方式完成。或者，如果图像最初是作为 POST 请求加载的，我想它也可以重定向 POST，但不会更改 POST 数据。所以这是相当安全的。

最后但同样重要的是，如果攻击者控制了例如论坛头像（例如在 SMF 论坛中）的 URL，就有可能从访问者那里获取信息，例如他们的 IP 地址。我前段时间写了一个工具，它使用action=whoSMF 的页面将 IP 地址链接到用户名。当我开始向用户显示它时（在图像中显示“Hello $username with IP: $IP”），一切都乱了套。“你怎么可能知道？！” 他们大多是早到中年的技术人员，所以他们知道 IP 地址是什么，但不知道我无法用它破解他们。然而，至少在荷兰，它被认为是个人身份信息，因此管理员对这种做法不太满意。如果你不显示它，没有人会知道。

注意：如果这篇文章看起来很仓促，那就是。我也快睡不着了。也许我明天会清理它，如果它讲故事太多并且没有命名足够的具体事实和漏洞。无论如何，希望这有所帮助！

IMG 标签将尝试将数据解释为图像，因此不会执行 Javascript。

有可能发送的图像一旦解码就需要大量内存（“PNG 炸弹”），并且图形例程本身可能容易受到恶意内容的攻击（精心制作的图像，在解码后，触发嵌入代码的执行）。大约十年前就有这样的漏洞，虽然不太可能，但可能会出现另一个漏洞。

更新：另一个做了。还有一个，这个有 9.3 的 CVSS 分数——“系统完整性完全受到损害。系统保护完全丧失，导致整个系统受到损害”

然后，该HTTP_REFERER标签将允许图像站点的所有者知道访问过哪些页面，并通过使用跟踪 cookie，可能会泄露一些信息（例如，恶意站点托管了一个在站点 A、B 和站点之间共享的图像） C. 图像的所有者可以看到站点 A 上的给定用户与站点 B 的另一个用户是同一个人，因为图像在站点 A 上使用时设置了一个 cookie，而现在相同的 cookie 来自站点 A 的用户站点 B)。根据具体情况，这可能是不可取的。

通过嵌入主机站点设计的图像部分，攻击者可能会诱使用户相信该站点托管了一些实际上并不存在的内容。这要求 HTML/CSS 容易受到图像大小突然变化的影响。例如，一个证券交易所网站可能会显示一个 200x600 的横幅来代替 200x80 的横幅，其最上面的行与原始横幅相同，下面的部分是为模拟证券交易所网站而设计的，并被“推过”股票股票代码，并复制相同的股票代码 - 但具有不同的价值。粗心的用户可能会被诱骗相信完全虚假的股票数据。如果有足够多的用户被说服，这可能会允许一种“泵和转储”方案。

据报道，这种情况经常发生的一种变体是当您在未经适当许可的情况下链接图像时。承担将图像提供给您的观众的费用的网站所有者有可能用完全不同的东西切换图像。这有时是事先故意完成的，即在适当的论坛中播种“多汁”的图像（例如与某个足球队的混搭？），然后用内容相反的东西切换（与该球队的主要竞争对手相同） . 为了增加乐趣，拖钓网站管理员可能会记录下载图像的原始 IP，并继续向他们发送原始图片。所以A队的球迷会宣传一个树莓对自己的团队，并且不明白为什么每个人都在笑 - 每次他们看到图像时，他们都会看到它在嘲笑 B 组。这可以作为一个警告：不要假设您看到的图像与您的用户看到的相同。

JavaScript 本身不会被执行，即使远程服务器将MIME Content-Type更改为text/javascript，因为浏览器会期望IMG标记中包含某些 MIME 类型。但这并不意味着它们可以安全使用。

我建议您阅读的一个主题是允许将外部图像附加到博客或任何 Web 内容是否安全？. 简而言之，您链接外部图像的服务器仍然可以从最终用户的浏览器发送给它们的 HTTP 请求中读取所有数据（即请求 IP 地址、用户代理字符串、协议版本，以及源自非 HTTPS request 还包括其他请求标头，其中包括引用URL 字符串，当然还有非安全的 HTTP cookie）。

远程服务器还可以动态生成图像，可能会引起其他问题（不适当的内容、通过添加最终用户请求信息（例如 IP 地址）来散布恐惧……），或者通过检查描述的 HTTP 请求标头来简单地跟踪服务器上的用户活动更早，或者在他们的响应中删除第三方跟踪 cookie。非安全 HTTP 请求的引用字符串中的URL 暴露通常被忽略，并且可能会暴露您可能不喜欢它们的服务器的 Web 地址（CMS 位置、URL 会话数据......）。对于不限于单个域（位置）并且可以被第三方读取甚至写入的非安全 cookie 也是如此。

此外，恶意代码可以通过未正确修补的客户端系统上的精心制作的图像传播。比较著名的此类漏洞之一是GDI+ 漏洞，该漏洞可能允许在未打补丁的早期版本的 Windows 上远程执行代码。还有其他类似的漏洞利用，其中一些仍未在所有系统上正确解决。

^{在一些最新的此类利用中，可以在某些浏览器[1] [2]}上从特制的 SVG 图像触发 Java（不是 JavaScript）代码：

Exploit-DB - 从 SVG 图像触发 Java 代码：

SVG 是一种基于 XML 的文件格式，用于静态或动画图像。一些 SVG 规范（如 SVG 1.1 和 SVG Tiny 1.2）允许在打开 SVG 文件时触发一些 Java 代码。

和

Metasploit - Squiggle 1.7 SVG 浏览器 Java 代码执行：

该模块滥用 SVG 支持，通过引用 jar 文件的精心制作的 SVG 文件在 Batik 框架 1.7 中包含的 Squiggle 浏览器中执行 Java 代码。为了获得任意代码执行，浏览器必须满足以下条件：（1）必须至少支持 SVG 1.1 或更新版本，（2）必须支持 Java 代码和（3）“强制安全脚本”检查必须被禁用。该模块已针对 Windows 和 Linux 平台进行了测试

更多关于可能的 SVG 漏洞可以在漏洞利用或 SVG 上传的其他安全风险中阅读？线。

因此，简而言之，它不太安全，可能取决于您对要链接图像的远程服务器的信任，而不是利用它。

是的，你很安全。

当然，当您右键单击 > 查看图像时获得的页面可能是恶意的，但不会在您的网站上下文中执行任何脚本。

此外，不要忘记图像网站的所有者可以在嵌入图像的所有页面上跟踪您的访问者。