图片上传 - 安全问题 [英] Image Uploading - security issues

问题描述

我开发一个ASP.NET Web App和希望用户能够要么从本地系统上传图片，或在URL传递到图像。该图像可以是JPG或PNG。我应该是什么样的安全问题担心这样做呢？我见过的JPG文件中嵌入code的各种方法。有没有在C＃（或外部库）能确认一个文件是JPG / PNG的任何方法，否则抛出一个错误？最起码，我正在做它保存上传的图片不可浏览，并把1MB的最大尺寸限制目录，但我想实现进一步的检查。

感谢您的任何建议。

解决方案

  

有没有在C＃（或外部库）能确认一个文件是JPG / PNG的任何方法，否则抛出一个错误？

也许吧，但并没有真正本身的帮助。你可以很容易地使文件，既是一个有效的图像格式的和的包含主动HTML /脚本内容IE内容嗅探到绊倒。或者，再有就是破碎的Java和Flash起源政策担心，它可以有脚本到服务器的安全上下文同样的效果。

1. 如果您处理图像（如裁剪，调整大小），并重新保存，使得它非常非常困难的事走私内容的攻击。然而，你应该始终确保你的服务器端工具是先进的日期，在图像处理库的漏洞可能会使您服务器端的开发。




2. 如果你不能做到这一点，最好的办法作为所有内容的注入问题缓解是从不同的[子]域为你的图片不访问任何敏感的凭据主要网站（饼干，基本身份验证）。




3. 如果使用用于此目的的子域名，如 images.example.com ，你的主要的网站应该是可访问的只有的通过 www.example.com 和不的 example.com 。否则，内容注入到 images.example.com ，可以在IE访问了 example.com 饼干。 example.com 应301重定向到 www.example.com 来prevent不必要的cookie泄漏一般。




4. 添加标题 X-Content-Type的选项：nosniff 来应对阻止IE8内容走私的攻击。 （不与早期版本的帮助，唉。）

还有：

1. Sanitising用户指定的文件名是的硬盘的，特别是如果你的应用程序很可能是一个Windows服务器，其中约可用文件名的规则确实是复杂的运行。一个良好的开始是只允许字母数字，并添加自己的文件扩展名和preFIX。 （A preFIX是必要的，以避免在Windows保留文件名和空的文件名）。




2. 更好的：存储在数据库中的用户提供的文件名，而不是使用它作为一个真正的文件名

请参阅this问题对于文件上传的安全问题进行更多的讨论。

I'm developing an ASP.NET Web app and would like the user to be able to either upload an image from their local system, or pass in a URL to an image. The image can either be a JPG or PNG. What security issues should I be concerned about doing this? I've seen various ways of embedding code within JPG files. Are there any methods in C# (or external libraries) which can confirm that a file is a JPG/PNG, otherwise throw an error? At the very least, I'm making the directory which holds uploaded images non-browsable and putting a max size limit of 1mb, but I'd like to implement further checks.

Thanks for any advice.

解决方案

Are there any methods in C# (or external libraries) which can confirm that a file is a JPG/PNG, otherwise throw an error?

Maybe, but that doesn't really help in itself. You can easily make file that is both a valid image format and contains active HTML/script content for IE content-sniffing to stumble on. Or then there's the broken Java and Flash origin policies to worry about, which can have the same effect of scripting into your server's security context.

1. If you process the image (eg. crop, resize) and re-save that makes it very, very difficult to do content-smuggling attacks. However, you should always ensure that your server-side tools are up-to-date, as vulnerabilities in image processing libraries might expose you to server-side exploit.

2. If you can't do that, your best bet as a mitigation for all content-injection problems is to serve your images from a different [sub]domain which doesn't have access to any of the sensitive credentials (cookies, basic auth) of the main site.

3. If using a subdomain for this purpose such as images.example.com, your main site should be accessible only through www.example.com and not example.com. Otherwise, content injected into images.example.com can access cookies for example.com in IE. example.com should 301-redirect to www.example.com to prevent unwanted cookie leakage in general.

4. Add the header X-Content-Type-Options: nosniff to the response to block content-smuggling attacks from IE8. (Doesn't help with earlier versions, alas.)

Also:

1. Sanitising user-specified filenames is hard, especially if your app is likely running on a Windows server where the rules about usable filenames are complicated indeed. A good place to start is allowing only alphanumerics, and adding your own file extension and prefix. (A prefix is necessary to avoid the Windows reserved filenames, and the empty filename.)

2. Better: store the user-supplied filename in the database instead of using it as a real filename.

See this question for more discussion of file upload security problems.

这篇关于图片上传 - 安全问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！