gpt4 book ai didi

javascript - 处理用户上传图片时防止 'content-sniffing'类型漏洞?

转载 作者:搜寻专家 更新时间:2023-10-31 21:47:24 24 4
gpt4 key购买 nike

问题:

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

这是一个 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 显示为损坏的链接 - 最重要的是没有恶意内容被解释!

但是如果用户右键单击这个断开的链接,然后单击“查看图像”...就会发生不好的事情。

浏览器执行“内容嗅探”这个对我来说很新的概念,检测到“maliciousImage.jpg”实际上是一个文本文件,并且非常友善地毫不犹豫地将其呈现为 HTML。任何脚本标记都会传递给 JavaScript 解释器,正如您所想象的,我们不希望这样。

到目前为止我尝试了什么

简而言之,我能想到的每一种可能的响应头组合都可以防止浏览器进行内容嗅探。我在 stackoverflow 和其他文档上找到的所有答案都暗示设置内容类型 header 应该阻止大多数浏览器进行内容嗅探,设置 X-content 选项应该阻止某些版本的 IE。

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

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

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

我也尝试过在上传时检测哪些图像是恶意的,哪些不是恶意的,但我很快意识到这非常重要......

最终目标:

自然 - 任何不是真正图像的图像输出(乱码、未处理的异常等)都比将文本文件作为 HTML/javascript 以明文形式执行,但将任何恶意 HTML 显示为更好转义/CDATA'd 纯文本将是理想的......虽然可能有点不切实际。

最佳答案

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

第 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 步:框架愚蠢

事实证明,有一整套我从未接触过的后处理工作流程,它执行诸如将标记附加到响应主体以及使用其他框架通过 CSS、页眉、页脚等装饰响应等操作。

这意味着,尽管 Controller 显式返回 image/png,但它被抓取并放置(作为字节)后处理采用该字节流,并将其包装在页眉和页脚中,以形成完全合格的“ View ” ' - 此 View 始终具有“内容类型”文本/html,因此从未正确显示。

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

所以我不得不逐步完成这个工作流程,并在我的代码中为 Controller 创建异常,这些 Controller 返回的内容不是以 Restful 方式工作。

例如对于 site-mesh 它只是一个排除(一如既往,一旦我理解了问题就简单修复...):

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

然后是其他一些定制的调用后拦截器。

第 3 步:内容协商

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

一个名为“内容协商”的 Spring 特性开始发挥作用。它试图协调请求的“接受” header 与它手头的“消息转换器”以产生此类响应。

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

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

@Produces("image/png")

到我的 Controller - 简单修复...

第 4 步:遗留依赖项

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

我尝试注册新的 messageconverters 但那很让人头疼,或者添加一个新的后方法拦截器来简单地将内容类型改回 'image/png' - 但那是一件令人头疼的事情。

最后我只是在 Controller 中公开了请求/响应,并将我的图像直接写入响应主体——完全绕过了 Spring 的内容协商

....最后我的图像被用作图像并显示为图像 - 没有执行任何注入(inject)的代码!

关于javascript - 处理用户上传图片时防止 'content-sniffing'类型漏洞?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/34288688/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com