接受图像上传时的安全问题
除了所有 HTTP 上传的正常内容之外，接受图像上传时还需要考虑哪些主要安全问题？
我接受图像上传，然后向其他用户显示这些图像。
例如，我应该如何验证上传的图像实际上是有效的图像文件？查看器中是否存在可被格式错误的图像文件利用的已知漏洞，我应该担心意外传递漏洞？ （快速谷歌搜索似乎表明IE5 / 6中曾经有过。）
我是否应该剥离所有图像元数据以帮助用户防止无意的信息泄露？或者是否有一些安全、必要或有用的事情可以允许？
常见图像格式是否有任何可能成为安全漏洞的神秘功能？
有没有可以处理这些问题的库？ （和/或其他问题，例如将渐进式 JPEG 转换为普通 JPEG、下采样以标准化尺寸、优化 PNG 等）
What are the major security issues to consider when accepting image uploads, beyond the normal stuff for all HTTP uploads?
I'm accepting image uploads, and then showing those images to other users.
How should I verify, for example, that the uploaded image is actually a valid image file? Are there any known vulnerabilities in viewers that are exploitable by malformed image files for which I should be concerned about accidentally passing along exploits? (Quickly googling seems to show that there once was in IE5/6.)
Should I strip all image metadata to help users prevent unintentional information disclosures? Or are there some things that are safe and necessary or useful to allow?
Are there any arcane features of common image formats that could be security vulnerabilities?
Are there any libraries that deal with these issues? (And/or with other issues like converting progressive JPEGs to normal JPEGs, downsampling to standardize sizes, optimizing PNGs, etc.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我最近从网络安全视频中学到了一些东西：
Some things I learned recently from a web security video:
图像格式化程序内部传播错误的风险“完全”不是您的问题，但您无论如何都可以提供帮助，方法是遵循将“.jpg”映射到可执行语言的一般做法，并处理每个手动图像（通过这种方式，您也可以进行参考检查）。
您需要小心：
最后一个是您需要做的如果您正在动态地阅读图像（如果您遵循我的第一条建议，您将会这样做），请保持警惕。
因此，请确保您只打开相关文件夹中的代码，并且，可能更重要的是，锁定执行此工作的用户。我的意思是网络服务器用户。确保它仅具有从您正在使用的文件夹以及其他此类逻辑事物读取的权限。
剥离元数据？当然为什么不呢，你很有礼貌，但我不会对此生气。
The risk of propogation of bugs inside image formatters isn't "exactly" your problem, but you can help anyway, by following the general practice of mapping ".jpg" to your executable language, and processing each image manually (in this way you can do refer checks as well).
You need to be careful of:
The last one is what you'll need to be wary of, if you're dynamically reading in images (as you will be, if you follow my first bit of advice).
So ensure you only open code in the relevant folder, and, probably more importantly, lock down the user that does this work. I mean the webserver user. Make sure it only has permissions to read from the folder you are working in, and other such logical things.
Stripping metadata? Sure why not, it's quite polite of you, but I wouldn't be nuts about it.
您最大的风险是攻击者试图将某种类型的可执行代码上传到您的服务器。如果上传的文件可以在网络上浏览，则攻击者可能会导致代码在您的服务器上运行。最好的保护措施是首先将上传的文件保存到非公开可浏览的位置，尝试用您的编程语言将其作为图像加载，如果可以成功解析为图像，则允许它。很多时候人们无论如何都会想要调整图像的大小，所以真正这样做并不需要额外的工作。图像经过验证后，您可以将其移至 Web 服务器的公共可浏览区域。
另外，请确保您对文件上传大小有限制。默认情况下，大多数平台都会有某种限制。您不希望恶意用户无休止地上传文件来填满您的磁盘。
Your biggest risk is that an attacker tries to upload some type of executable code to your server. If the uploaded file is then browsable on the web, the attacker may be able to cause the code to run on your server. Your best protection is to first save the uploaded file to a non-publicly browsable location, try to load it as an image in your programming language and allow it if it can be successfully parsed as an image. A lot of the time people will want to resize the image anyway so really doing this is no extra work. Once the image is validated, you can move it into the publicly browsable area for your web server.
Also, make sure you have a limit on file upload size. Most platforms will have some kind of limit in place by default. You don't want a malicious user filling up your disk with an endless file upload.
我所知道的漏洞之一是“WMF 后门”。 WMF 是“Windows 图元文件”——一种由 Windows GDI 库呈现的图形格式。这是维基百科文章。
攻击者能够在用户的计算机上执行任意代码。当用户仅通过浏览器（包括但不限于 Internet Explorer）查看文件时，可能会发生这种情况。据说这个问题已于 2006 年得到解决。
One of the vulnerabilities I know of is a "WMF backdoor". WMF is "Windows Metafile"--a graphical format rendered by Windows GDI library. Here's wikipedia article.
The attacker is capable to execute arbitrary code on user's machine. This can happen when user just views the file via the browser, including, but not limited to Internet Explorer. The issue is said to be fixed in 2006.