图像上传 – 安全问题
我正在开发一个ASP.NET Web应用程序，并希望用户能够从本地系统上传图像，或者将URL传递给图像。 图像可以是JPG或PNG。 这件事我应该关注哪些安全问题？ 我已经看到了在JPG文件中嵌入代码的各种方法。 C＃（或外部库）中是否有任何方法可以确认文件是JPG / PNG，否则会抛出错误？ 至少，我正在制作保存上传图像不可浏览的目录，并将最大大小限制为1mb，但我想实施进一步的检查。
谢谢你的建议。
C＃（或外部库）中是否有任何方法可以确认文件是JPG / PNG，否则会抛出错误？
也许，但这本身并没有多大帮助。 您可以轻松地创建既是有效图像格式的文件， 又包含用于IE内容的活动HTML /脚本内容 – 嗅探绊倒。 或者需要担心破坏的Java和Flash原始策略，这可能与脚本进入服务器的安全上下文具有相同的效果。
-
如果您处理图像（例如裁剪，resize）并重新保存，则会使内容走私攻击非常非常困难。 但是，您应始终确保服务器端工具是最新的，因为图像处理库中的漏洞可能会使您暴露于服务器端漏洞。
-
如果您不能这样做，那么最好的办法是减轻所有内容注入问题，以便从不能访问任何敏感凭据（cookie，基本身份validation）的不同[子]域提供图像。主要网站。
-
如果为此目的使用子域（例如
images.example.com，则只能通过www.example.com而不是example.com访问您的主站点。 否则，注入images.example.com内容可以在IE中访问example.comcookie。example.com应该301重定向到www.example.com以防止不必要的cookie泄漏。 -
将标题
X-Content-Type-Options: nosniff添加到阻止来自IE8的内容走私攻击的响应中。 （对早期版本没有帮助，唉。）
也：
-
清理用户指定的文件名很难 ，特别是如果您的应用程序可能在Windows服务器上运行，其中有关可用文件名的规则确实很复杂。 一个好的起点是只允许使用字母数字，并添加自己的文件扩展名和前缀。 （必须使用前缀来避免Windows保留的文件名和空文件名。）
-
更好：将用户提供的文件名存储在数据库中，而不是将其用作真实文件名。
有关文件上载安全性问题的更多讨论，请参阅此问题。
这是一个绝对的雷区。 要考虑的事情（不一定是详尽的清单，没有保证等）。
- 有些人使用正则表达式进行解析，因此无法知道文件是否包含代码。 ZIP文件最后有他们的目录。 Sun / Oracle Java PlugIn / WebStart现在检查文件是否以ZIP本地标头/条目幻数开始，以避免“GIFAR”攻击。
- 服务于不同的域名，以避免同源问题。
- 从不同的IP地址服务，以避免同源问题。
- 检查文件是否正在利用，比如0天的缓冲区溢出，这有点棘手。 它甚至可能利用无限循环来创建DoS。
- 最好重新编码图像。
- 小心URL /文件路径名。 如果您提供选项，请使用白名单检查。 特别是NUL角色是“有趣的”。 另请参见目录遍历攻击。 通常，能够放置给定内容的文件的已知位置至少是一个大的狡猾。
- 或者您可能想要检查尺寸是否合理的图像。 解压缩巨大的图像很可能导致DoS。 还要注意，压缩算法通常允许通过巨大因素压缩琐碎数据。
不要让用户确定将在您的服务器上使用的文件名。 如果需要，请使用[generated guid] .jpg并将它们使用的文件名放在数据库表中。
请参见＃12： http ： //www.codinghorror.com/blog/2009/01/top-25-most-dangerous-programming-mistakes.html
文件名或路径的外部控制在构造文件名时使用局外人输入时，生成的路径可能指向目标目录之外。 攻击者可以组合多个“..”或类似的序列，以使操作系统导航到受限目录之外。 其他与文件相关的攻击通过文件名的外部控制（例如符号链接跟踪）得以简化，这会导致应用程序读取或修改攻击者无法直接访问的文件。 如果您的程序以提升的权限运行并且它接受文件名作为输入，则同样适用。 类似的规则适用于URL并允许局外人指定任意URL。
也要小心URL，确保它是一个绝对的外部URL，这样他们就无法使用您自己的Web服务器将局域网中的机密文件复制到他们可以访问它的区域，因为您将从中加载该URL在您的Web服务器上运行的代码。
您可以使用基础架构即服务来处理图像，例如我们的解决方案 – Uploadcare：
如果将任何图像操作应用于上载的图像，则会对其进行修改，因此可能会破坏可能嵌入到文件中的任何代码。