记某SRC忽略漏洞新姿势！！！

前言

看到某SRC举办了中秋活动，于是打算挖个垃圾洞蹭一下中秋礼包。想来想去什么洞最好挖呢？当然是XSS了！！

大家应该非常熟悉某个互联网厂商，它大多数业务的文件上传都是将文件上传到存储桶中，只是按照业务区域创建了不同地区的存储桶。

这个做法不言而喻，是为了防止更多的漏洞，比如文件上传 文件覆盖 XSS漏洞等，是一种非常好的安全实践。

漏洞详情

1、某开发者平台的上传功能测试路径：

在这个功能的文件上传的功能实现中，以图片类型文件的后缀作为白名单，符合后缀的文件会被上传到存储桶。

上传后的文件需要调用/i*/*Pic/get*Pic?picUrl=打开。

在进一步测试中，我发现另一个平台的上传路径与上述路径类似，还包含了文件扩展名。

这意味着这些接口使用的是相同的存储桶位置。但是在实际上传文件中，程序通过JavaScript生成serviceToken用于类似HMAC的消息认证码，这增加了攻击的难度。

如果GetPic没有固定Content-Type为image的情况下，我们总能在某个接口找到一个上传可执行脚本文件的扩展名。

除此之外还发现该接口的./profile似乎有Self-XSS...想考虑通过配合CSRF来进行攻击，但无法利用。

2、某支付业务的上传功能测试路径：

发现该功能点是通过黑名单来判断文件是否合规的逻辑。

经过多次测试发现，在文件后缀加一个=，就会绕过上传html文件。然而并不解析。

后来发现，是通过Content-Type: text/html来设置文件的格式。所以成功XSS了。

后续

在2024-09-03 17:36 提交给某SRC后，某SRC认为并不是上传点对于文件格式的上传限制存在缺陷，而是认为存储桶本来就不应该解析html文件，并且拿出了pdf的xss忽略标准。

值得搞笑的是，你家业务大多数用的都是存储桶，然后你以这个存储桶的配置错误来作忽略漏洞的理由？？那是不是所有上传到存储桶的XSS漏洞都不认了？

笔者早在2022年就提交了相同的存储桶XSS问题，这意味着这个仅仅需要加一个Content-Disposition: attachment头的问题被你们整治了两年半？？

截至2024-09-04 11:00 该漏洞已经被修复。也就是说漏洞提交到漏洞修复的时间不超过一天。

原文始发于微信公众号（墨雪飘影）：记某SRC忽略漏洞新姿势！！！