初探接口：被 Sign 挡住的重放之路

测试登录接口时，首先尝试对「获取验证码」接口进行重放测试。使用 BurpSuite 抓取请求包后，直接重放发现服务端返回错误，无法再次获取验证码。

仔细观察请求头，发现每个请求都携带了一个 `sign` 字段：

![图片](/media/202606/230ef7fa0db64f20b8a901e91a6f1bd83220.png)

直接开始逆向，先看下长度，32位，首先想到MD5加密

![图片](/media/202606/1d211e1aa2dd498a84debc7fec5595444235.png)

尝试关键词搜索sign，sign：，sign=

结果关联文件太多，不适合使用这种方式找；

![图片](/media/202606/c8d30697346c48cfb6241c724787cf7d2769.png)

换个方式，使用启动器分析

Promise.then() 可以看到是异步回调

![图片](/media/202606/95e3c28d2d61474994121a22f392a5372913.png)

:为了测试方便，验证码刷新接口有时间限制，换一个接口测试/page

![图片](/media/202606/49f0ac10e41742a09f2ec77749ad91f11595.png)

进入末尾，打断点，刷新页面，发现已经生成了sign的值；

![图片](/media/202606/9e9b912944c44e579f80cb46207d3dbc3247.png)

进入第一个异步栈v.request，发现这时的head为空，这里可以看出信息是在v里面的函数生成

![图片](/media/202606/e53f65c8884c475ea715b51f892353986659.png)

打开数组v里边存在很多方法，打开第二个方法，发现onrequest，这里可以看出t为请求参数，e()函数加载了t

![图片](/media/202606/c082e434f0b14290978676501af2a3811124.png)

进入e()方法，找到e.headers.sign生成的方式，现在只要找到这段代码中的未知函数，这就可以生成sign的值；

```
sign=(time = headers['time'], t = md(data),
```

最终函数的逻辑为：

![图片](/media/202606/2db4cef8b019406d8782ccc32539de124700.png)

![图片](/media/202606/6573db5a10c24674a7afbed0c2075dde3993.png)

接着继续找未知函数md()，pd()

先追md()函数

![图片](/media/202606/0d401871447b488ea9562b4dc54c04256975.png)

![图片](/media/202606/2d4681a5379b44adaa33e20d513358f28773.png)

md()函数中包含未知函数gd()和\_d()函数，继续向下，拿到gd()

![图片](/media/202606/514215d1d1e74a5c9ea495a4098ec0e94903.png)

回到md()函数，继续追\_d()函数

![图片](/media/202606/d94e1c4ef7e2410283fe95ab3f7040f73572.png)

接着找pd()函数，该函数中涉及未知fd()函数

![图片](/media/202606/60cf7a7395cc4b5bbe42b603056cbd613084.png)

找到fd()函数

![图片](/media/202606/836ff6edfbfc4042ae543dc6ce744ee83115.png)

进入fd()函数，发现该函数疑似MD5加密；推测是对n=t+e+time的MD5加密‘。

![图片](/media/202606/0dcb96e4ec6c4a518d1897027e0a15bb6305.png)

使用在线MD5加密平台验证，控制台获取n=t+e+time的值。

加密结果相同，均为：'02d932d40fabc5db9345f3309fb7d15a

![图片](/media/202606/153bb4b2331240d2ba9e5d88ac048aa62038.png)

![图片](/media/202606/f17f5eb4740f4eab92fbd682cf86470a1619.png)

到这里，我们就可以写pd()函数了

```
function md5(str) {
```

综上 所有的未知函数都已找到，可以说sign的值已经出来了。

## 脚本测试

使用js脚本生成时间戳timestamp值和sign值

![图片](/media/202606/4878f4feb9d94249b7d15b5f91bf26434195.png)

使用py脚本调用js，修改验证码请求包，两个手机号码同时收到验证码；

![图片](/media/202606/a718778494914515aa227ad46c4c569a9723.png)

测试结果显示：**攻击者手机与受害者手机几乎同时收到了相同的验证码短信**。

这意味着服务端存在严重的逻辑缺陷：

*   `sign` 校验仅验证了请求合法性（防篡改、防重放），**但并未将验证码与目标手机号在服务端建立强绑定**。
    
*   或者，验证码在某一时间窗口内对所有手机号生效（全局验证码池）。

![图片](/media/202606/2b187c47798a49a38ea8b075bf834e761331.png)

到这里就造成了任意用户登录漏洞！

任意用户登录的闭环

攻击者拿到受害者手机收到的验证码后（若配合社工、SIM 交换、或运营商短信劫持等场景），直接在登录接口输入：

```
手机号：13900139000（受害者）
```

由于验证码本身合法且在有效期内，服务端校验通过，攻击者成功登录受害者账户，完成**账户接管（Account Takeover）**。

JS逆向签名链到任意登录