内容未知的图像：对浏览器有危险吗？
假设我允许用户链接到他们喜欢的任何图像。将检查链接的语法正确性、转义等，然后插入
是否存在任何已知的安全漏洞，例如有人链接到“evil.example.com/evil.jpg”，并且evil.jpg包含一些由于浏览器错误或类似问题而执行的代码？
（让我们忽略 CSRF 攻击 - 我只允许具有典型图像文件后缀的 URL 就足够了。）
Let's say I allow users to link to any images they like. The link would be checked for syntactical correctness, escaping etc., and then inserted in an <img src="..."/> tag.
Are there any known security vulnerabilities, e.g. by someone linking to "evil.example.com/evil.jpg", and evil.jpg contains some code that will be executed due to a browser bug or something like that?
(Let's ignore CSRF attacks - it must suffice that I will only allow URLs with typical image file suffixes.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
图像文件的安全风险时常出现。这是一个示例： https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-22_11-5388621.html?tag=nl.e019。这是一篇旧文章，所以显然这些事情已经流传了一段时间了。
虽然不可能肯定地说某些东西总是安全/永远不安全，但到目前为止，听起来风险相对较低，并且图像查看器制造商很快就修补了。 IMO 最好的测试是您听到实际问题发生的频率。这种威胁媒介多年来一直是已知的可能性，但尚未真正广泛传播。考虑到人们在公共论坛中链接图像的程度，如果这是一种现实的攻击，我预计它很快就会成为一个大问题。
Security risks in image files crop up from time to time. Here's an example: https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-22_11-5388621.html?tag=nl.e019. It's an old article, so obviously these things have been rolling around for a while.
While it's impossible to say for sure that something is always safe/never safe, so far it sounds like the risks have been relatively low, and are patched by the image viewer manufacturers pretty quickly. IMO the best test is how often you hear about actual problems occurring. This threat vector has been a known possibility for years, but hasn't really become widespread. Given the extent to which people link images in public forums, I'd expect it to become a big problem pretty quickly, if it was a realistic sort of attack.
不久前发生了JPEG 缓冲区溢出。此外，您还必须考虑实际包含代码的图像，这样您就不会执行代码。
There was a JPEG buffer overrun some time ago. Also, you have to account for images who actually contain code, so that you don't execute the code.
是的，这可能是个问题。有相当多的已知漏洞是通过利用浏览器或操作系统的图像渲染代码中的漏洞来实现的。包括远程执行漏洞。这可能不是最容易利用的缺陷，但它绝对是一个问题。
此类漏洞的示例： http://www.securityfocus.com/bid/14282/discuss （但您可能会发现大量相同类型的其他漏洞）。
我想我记得这样一个问题，一个高知名度的网站正是利用了这种漏洞。显示来自某些第三方广告提供商的广告图像，且该图像未经检查。数千名用户受到损害...无法再找到该故事...抱歉。
Yes, this could be a problem. There is quite a few exploits known that work by using vulnerabilities in the image rendering code of the browser or the OS. Including remote execution vulnerabilities. It might not be the easiest flaw to exploit, but it is definitly a concern.
An example of such a vulnerability : http://www.securityfocus.com/bid/14282/discuss (but you could find tons of other vulnerabilities of the same type).
I think I remember such a problem with a high visibility site having exactly this kind of vulnerability exploited. An advertisement image was displayed from some third party ad provider, and the image had not been checked. 1000's of users compromised ... Cant find the story anymore ... sorry.
因此，无论您如何处理不受信任的数据，都存在潜在的缓冲区溢出问题。此外，如果您以 URL 的形式将不受信任的数据插入到页面中，则存在 XSS 缺陷的风险。但是，我想您想知道为什么浏览器将其标记为问题：
我突然想到：
我相信在这种情况下仍然会发送推荐人信息。即使您现在和将来都不会对会话使用 URL 重写，您仍然会暴露以前机密的信息。 chris_l：确实，我刚刚做了一个快速测试 - 浏览器（FF 3.5）发送Referer标头。
您无法确定返回的图像数据不会产生误导。例如，按钮上的文字错误。或者在更大的图像中，例如欺骗指令。
图像尺寸可能会改变布局。甚至可以延迟图像加载以在关键时刻移动页面。 chris_l：好点！我应该始终设置宽度和高度（可以在用户发布图像时由服务器确定 - 只要图像不改变就可以工作......更好的想法？）
可以使用图像用于类似 AJAX 的功能。 chris_l：请详细说明这一点 - 它是如何工作的？
浏览器会标记您网站的问题，隐藏其他问题并引导用户接受宽松的安全实践。 chris_l：当网站使用 HTTPS 时，这绝对是一个重要问题。
So there's potential buffer overflows with handling untrusted data, however you get to it. Also if you insert untrusted data in the form of URLs into your page then there is a risk of XSS flaws. However, I guess you want to know why browsers flag it as a problem:
Off the top of my head:
I believe referrer information is still sent in this case. Even if you don't ever and wont ever use URL rewriting for sessions, you are still exposing information that was previously confidential. chris_l: True, I just did a quick test - the browser (FF 3.5) sends the Referer header.
You cannot be sure that the image data returned will not be misleading. Wrong text on buttons, for instance. Or in bigger images, spoofing instructions, say.
Image size may change layout. Image loading could even be delayed to move page at a critical time. chris_l: Good point! I should always set width and height (could be determined by the server when the user posts the image - would work as long as the image doesn't change... better ideas?)
Images can be used for AJAX-like functionality. chris_l: Please expand on this point - how does that work?
Browsers will flag an issue with your site, hiding other problems and conditioning users to accept slack security practices. chris_l: That's definitely an important problem, when the site uses HTTPS.
更新：已证明错误！
您还必须考虑，cookie（即 sessionID）也会发送到图像所在的服务器。这样另一台服务器就会获取你的sessionID。如果图像实际上包含 PHP 代码，它可能会窃取 sessionID：
例如，您包含：
在 http://example.com 的服务器上 有一个 .htaccess 文件说了以下内容：
那么图片实际上是一个 php 文件，生成图像，但也会做一些邪恶的事情，例如会话窃取或其他什么......
UPDATE: Proofed wrong!
You also have to consider, that cookies (that means sessionIDs) are also sent to the server where the image is located. So another server gets your sessionID. If the image actually contains PHP-Code it could steal the sessionID:
For example you include:
On the server of http://example.com there's a .htaccess-file saying the following:
then the pic actually is a php-file, generating the image, but also do some evil stuff, like session-stealing or whatever...