在处理 user-uploaded 图像时防止 'content-sniffing' 类型漏洞？

Question

问题：

我在开发一个允许用户上传图像的内部工具，然后将这些图像显示给他们和其他人。

这是一个 Java/Spring 应用程序。我的好处是只需要确切地担心 IE11 和 Firefox v38+（Chrome v43+ 会很不错）

第一次开发该功能后，用户似乎可以创建一个文本文件，如：

 <script>alert("malicious code here!")</script>

并将其另存为“maliciousImage.jpg”并上传。

稍后，当该图像显示在图像标签内时，例如：

 <img src="blah?imgName=foobar" id="someImageID">

actualImage.jpg 正常显示，maliciousImage.jpg 显示为损坏 link - 最重要的是没有恶意内容被解释！

但是如果用户 right-clicks 在这个损坏的 link 上点击 'view image'... 不好的事情发生了。

浏览器做了 'content-sniffing' 一个对我来说很新的概念，检测到 'maliciousImage.jpg' 实际上是一个文本文件，并且非常友好地毫不犹豫地将它呈现为 HTML。任何脚本标签都会传递给 JavaScript 解释器，正如您所想象的，我们不希望这样。

到目前为止我尝试了什么

简而言之，我能想到的每一种可能的响应组合header都会阻止浏览器content-sniffing。我在 Whosebug 和其他文档上找到的所有答案都暗示设置 content-type header 应该阻止大多数浏览器 content-sniffing，设置 X-content 选项应该阻止某些版本的 IE。

我正在将 x-content-type-options 设置为不嗅探，并且正在设置响应内容类型。我读过的文档让我相信这应该停止 content-sniffing.

response.setHeader("X-Content-Type-Options", "nosniff"); 
response.setContentType("image/jpg");

我正在拦截响应，这些 header 存在，但似乎对恶意内容的处理方式没有影响...

我也试过在上传时检测哪些图片是恶意的，哪些不是恶意的，但我很快意识到这是非常重要的 non-trivial...

最终目标：

自然 - 任何不是真正图像的图像输出（乱码、未处理的异常等）都比将 text-file 作为 HTML/javascript 清晰地执行更好，但是将任何恶意 HTML 显示为 escaped/CDATA 的 plain-text 将是理想的......虽然可能有点不切实际。

Answer 1

adeneo 非常准确。您应该使用任何您想检查的图像库来检查上传的文件是否是它声称的类型的有效文件。客户端发送的任何内容都可以被操纵。

Answer 2

这听起来很奇怪，因为它在其他地方工作得很好。您确定 X-Content-Type-Options header 出现在回复中吗？

这是我不久前制作的一个演示，其中我有一个有效的 html、gif 和 javascript 文件。如您所见，它首先加载为 HTML，但随后将其自身加载为图像和脚本（执行）：
http://research.insecurelabs.org/content-sniffing/gifjs.html

但是，如果您使用 "X-Content-Type-Options: nosniff" header 加载它，脚本将不再执行：
http://research.insecurelabs.org/content-sniffing/nosniff/gifjs.html

顺便说一句，图像在 FF/IE 中正确呈现，但在 Chrome 中不正确。

这是一个演示，我在其中尝试了您所描述的内容：
http://research.insecurelabs.org/content-sniffing/stackexchange.html

第一张图片没有 nosniff，第二张图片有，它似乎按预期工作。当用 "view image".

打开时，第二个没有运行脚本

编辑：
Firefox 似乎不支持 X-Content-Type-Options: nosniff

因此，您还应该在图像中添加 "Content-disposition: attachment;filename=image.gif" 或类似内容。如果通过图片标签加载图片会正常加载，但如果直接打开URL，将强制下载而不是直接在浏览器中显示图片。

示例：http://research.insecurelabs.org/content-sniffing/attachment/

Answer 3

所以我最终解决了这个问题，但忘了回答我自己的问题：

第 1 步：屏蔽无效图片

为了快速解决问题，我只是添加了一些相当直截了当的代码来检查图像是否实际上图像 - 在上传期间和提供之前，使用 imageio 库:

import javax.imageio.ImageIO;

//...... 

Image img = attBO.getImage(imgId);
            
InputStream x = new ByteArrayInputStream(img.getData());
BufferedImage s;
try {
    s = ImageIO.read(x);
    s.getWidth();
} catch (Exception e) {
    throw new myCustomException("Invalid image");
}

现在，最初我希望这能解决我的问题 - 但实际上并没有那么简单，只是让生成有效载荷变得更加困难。

虽然这会阻塞：

 <script>alert("malicious code here!")</script>

很有可能生成同时也是 XSS 有效负载的有效图像 - 只需付出更多努力....

第 2 步：框架愚蠢

原来有一个完整的 post-processing 工作流程，我从未接触过，它做了一些事情，比如将标记附加到响应主体，并使用额外的框架来装饰 CSS 的响应，headers、页脚等

这意味着，虽然控制器显式返回 image/png，但它被抓取并放置（作为字节）post 处理正在获取该字节流，并将其包装在 header 和页脚，以形成完全限定的 'view' - 此视图始终具有 'content-type' text/html，因此从未正确显示。

这个问题的症结在于我的控制器以 RESTful 的方式直接返回图像，而构建框架的其余部分是为了处理返回完整视图的控制器。

所以我不得不逐步完成这个工作流程，并在我的代码中为控制器创建异常，这些异常返回的东西不是以 restful 方式工作的。

例如对于 site-mesh 它只是一个排除（一如既往，一旦我理解了问题就简单修复...）：

<decorators defaultdir="/WEB-INF/decorators">
<excludes>
    <pattern>*blah.ctl*</pattern>
</excludes>
<decorator name="foo" page="myDecorator.jsp">
    <pattern>*</pattern>
</decorator>

然后是其他一些定制的 post-invocation 拦截器。

第 3 步：内容协商

现在，我终于到了只提供图像字节码并且没有指定或明确生成评论的阶段。

一个名为 'content negotiation' 的 Spring 功能被启动。它试图协调请求的 'accepts' header 和它在 'messageconverters'手做出这样的回应。

因为 spring 默认情况下没有消息转换器来生成 image/png 响应，所以它退回到 text/html - 我仍然看到问题。

现在，如果我使用 spring 4，我可以简单地添加注释：

@Produces("image/png")

到我的控制器 - 简单修复...

第 4 步：遗留依赖项

但是因为我只有 spring 3.0.5（并且无法升级）我不得不尝试其他东西。

我尝试注册新的 messageconverters 但这是一个令人头疼的问题，或者添加一个新的 post-method 拦截器来简单地将 content-type 改回 'image/png' - 但那是一个令人头疼的问题。

最后我只是在控制器中暴露了 request/reponse，并将我的图像直接写入响应 body - 完全绕过了 Spring 的 content-negotiation

..最终我的图像被用作图像并显示为图像 - 没有执行任何注入代码！

在处理 user-uploaded 图像时防止 'content-sniffing' 类型漏洞？

Preventing 'content-sniffing' type vulnerabilities when handling user-uploaded images?

javascript

html

security

xss

penetration-testing

问题：