不是漏洞的挖掘者，只是漏洞的复现人。下面分享几个如果没有 AI 辅助，纯靠手工很难挖到的漏洞案例。
案例一：登录框背后的 SSRF
一个见过八百次的登录框，手工测试基本没出过任何东西。
经常挖教育行业 SRC 的师傅肯定对这个界面很眼熟。这次直接丢给 AI 去打，竟然真的跑出一个 SSRF 漏洞。
探测内网
访问本地默认的 80 端口：
访问不存在的 8081 端口：
访问存在的 443 端口：
访问不存在的 22 端口：
两组数据一对比，成功确认了 SSRF 漏洞的存在。
案例二：任意文件读取直达配置文件
因为是批量找资产测试的，有些资产访问后会重定向到统一认证页面，这正好解释了为什么这类漏洞很难复现，也很难通过手工测试发现。
漏洞详情
AI 挖这种接口以及未授权增删改查漏洞，确实有自己的一套手法。
在某值班系统的后端接口 /api/ms-duty/dutyManage/dutyPexxxemplateExport 中，查询参数 fileName 被直接拼接到模板文件路径里，既没有做路径规范化，也没有白名单校验。更要命的是，这个接口根本不需要登录 token。
攻击者可以直接传入 ../application-prod.yml 、 ../application-dev.yml 、 ../application.yml 等路径，任意读取服务器端的 Spring 配置文件。
案例三：白页面的逆袭——JWT 签名未校验
这个案例就更神了。
直接访问资产就是一个白页面，什么内容都没有。
一个接口都没发现。
这种情况下 AI 都能找到漏洞？
某一体化系统的移动端 API /zby-api/auth/token/jwt ，在将 CAS 下发的 Id-Token（也就是 JWT）换取业务会话时，竟然没有校验 JWT 的签名。
攻击者可以在本地构造任意 payload（只需要知道或枚举出工号），签名字段随便填，就能换取到真实的 token ，进而以对应用户的身份调用那些需要授权的教师端接口，比如课表、个人信息、借用、请假、考勤等操作。
前端 /mobile/ 的代码里硬编码了 API 基址和请求签名密钥 d1fedd9bbxxxa6edbf1fa （MD5 $key$_$timestamp$ ），但这个签名仅仅用来校验请求的完整性，并不能替代登录鉴权。实测结果：
- 工号
20xxx01 → 姓名「任xx」+ 课表数据
- 工号
20xxx02 → 姓名「张xx」
- 工号
xx2x003 → 姓名「xx欣」
整个过程，既不需要 CAS 账号，也不需要有效密钥，黑盒状态下就能完成任意教师的身份登录。
首先是在 /mobile/ 找到的突破口。如果是手工测试，碰到这种白页面，我们可能会去扫描全端口，或者扫目录，翻找 JS 文件来突破。其实只需要拼接这个 /mobile/ 路径，页面就会发生重定向。虽然重定向后看起来还是个白页面，但实际上已经能抓到很多接口了。
看到接口就能挖到了吗？不不不。
复现步骤
- 访问
https://42.xxxx2/mobile/ 获取前端 JS，确认 API 基址为 /zby-api，登录回调使用 X-Id-Token 调用 /auth/token/jwt。
- 构造伪造的 JWT。其中
alg=HS256，payload 包含 sub 与 preferred_username 为真实工号，exp 合法 Int32，签名任意。例如：
eyJhbGciOiJIUzIxxxIsInByZWZlcnJlZF91c2VybmFtZSI6IjIwMjEwMDAxIiwiZXhwIjoyMTQ3NDgzNjQ3fQ.forged
- 发送 GET 请求到
https://42xxxx2/zby-api/auth/token/jwt?type=0&jwt=伪造JWT（其中 type=0 代表教师），响应会返回 success=true 并给出 data.token。
- 用上一步拿到的 token，在请求头中携带它，访问
GET /zby-api/t-api/user/info，就能获取到工号、姓名等敏感信息。
- 继续访问
/zby-api/t-api/kb/index 等业务接口，读取课表等需要登录才能看的数据。更换工号就可以枚举其他教师的信息。
复现步骤详解
第一步：构造伪造JWT
JWT 由三部分组成：Header + Payload + Signature。
-
Header（Base64编码）
{"alg":"HS256","typ":"JWT"}
Base64 编码后： eyJhbGciOxxxxR5cCI6IkpXVCJ9
-
Payload（Base64编码），以工号 20xxx01 为例：
{"sub":"202xxx01","preferred_username":"20210001","exp":2147483647}
Base64 编码后： eyJzdWIiOiIyMDIxxxnByZWZxxxSI6IjIwMjEwMDAxIiwiZXhwIjoyMTQ3NDgzNjQ3fQ
-
Signature（任意值，反正服务端不校验）
forged
-
完整的伪造 JWT：
eyJhbGciOiJIUzI1NiIsxxxxx
JWT常见漏洞
这个漏洞产生的根本原因，就是签名没有被校验。
发送请求，利用构造的JWT换取Token
利用获取到的token，测试获取工号对应人的信息，证明token可用
获取其他信息，比如课表信息，其他接口不再一一截图
工号获取
方式一：直接枚举。从格式看，很明显是年份加4位数字组成，完全可以爆破。
方式二：直接用 Google 搜索收集。
site:xx.edu.cn 工号
还有意外收获，可以看到某系统的初始密码。直接随便找一个链接访问，就能看到工号，这里也直接说明了工号的规则。
理论上，攻击者完全可以伪造所有教师的信息进行查看等操作。
案例四：证书站的信息泄露
一个看起来和静态页面一模一样的网站，手工测试大概率会直接跳过。但让 AI 批量去打，AI 可不会轻易跳过任何一个目标。
结果还真就发现了好东西。写报告的时候搜了一下，网上根本搜不到这个压缩包，它的命名和域名也完全没关系。问了下 AI，它说是从响应包里提取的 URL 然后进行构造的，有点意思。
漏洞详情
目标网站根路径下暴露了一个约 680MB 的整站备份包 zxxxxxp.zip，无需登录就能完整下载。包里是某静态站及相关材料。
整个利用链如下：通过未授权 GET 请求下载主包 → 解压嵌套的压缩包 zxxxx/pdf/3/34/342/3423.zip → 得到一份毕业论文查重报告 xlsx（2019–2021）→ 其中名为「xxxx批次」的工作表里，「学号」那一列实际写入的竟是 18 位身份证号。
这几案例也说明了一点：在现在的 渗透测试 和漏洞挖掘里，巧用 AI 确实能突破很多传统手工测试的盲区。
发表于 3 小时前
|
查看: 4|
回复: 0
