奇安信攻防社区-漏洞挖掘-业务响应状态码攻击面新思路

漏洞挖掘-业务响应状态码攻击面新思路

挖掘了几个有意思的逻辑漏洞,均与响应状态相关,功能点关键的请求包执行完成,但是后端并没有返回有效的校验字段,如 openid token 等可猜测后端验证并不严格,引出响应状态码思考...文章为笔记复制故无社区水印,欢迎转载但请标明社区原创地址

### 任意用户登录接管

利用一处信息泄露二要素,结合未验证的响应包打出一套有效的任意用户登录接管;漏洞均已修复,相关数据包已改变,利用部分截图佐证，忽略信息收集直入主题,锁定景区服务小程序,对功能点逐一测试,景区业务重点**关注信息泄露及逻辑越权**

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102743368-95c454af-efba-4894-81c5-3f8af114450e.png "null")

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102743438-853e92f2-9345-4b61-9bee-bd2be5ff39a7.png "null")

测试到我的意见功能点,正常清空所有历史记录,再点击功能点看整个请求是发了那些数据包,这也是测试站点时所要完成的前置事情,一个功能点一整个历史记录,避免掺杂其他包影响判断

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102743499-e8d52613-8746-49fe-85bd-eea5b3e85a0f.png "null")

由于修复站点截图不全,故写出关键结论,填写必写值后提交`BP`历史收到请求,排序一下数据包序列,再逐一观察定位到此接口会记录下回显个人信息,浏览器发包测试,正常无需鉴权字段亦会出现数据,并且明文`ID`可遍历,泄露二要素信息

```php
https://xxxx/minibgs2/public/index/suggest/sug_info/?id=570
```

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102743574-f0f59858-9f8f-417c-83ba-78c778c93d74.png "null")

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102743638-3af91c2a-e058-4de5-ab6b-f4f568cd2c84.png "null")

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102743697-0b24dae7-c0cf-4ce9-bb95-17ef3472f84d.png "null")

将需要给予`AI`遍历`url`中 `id`值并写入正则匹配姓名电话,结束后记录值保存在`xlsx`表格共拿下`5k`人员二要素信息,此为任何用户接管契机

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102743778-083bfd38-2f1e-4215-9f93-7b5e65e5c7a7.png "null")

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102743853-2e019916-b1a5-4598-890f-c25a313750b6.png "null")

继续测试站点其他业务,我的套餐劵功能点是一处登录框需要手机号进入里面记录了个人景区订购酒店订单信息

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102743921-29fe2362-5a36-407a-8a39-adbaac519744.png "null")

手机号接收验证码登录,登录完成的响应包是这里形式,后端并未返回任何鉴权字段,只有一个`data`参数并且非常像`Base64`编码,直接利用插件解码,发现鉴权的参数竟然就是自身手机号+固定数字`0572030`,但是此站后续利用其他账号登录微信,将上方表格的号码进行编码制作响应包,在登录处进行拦截返回包替换为其他号码的即可顺利接管他人账号操作订单信息

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102743989-68745854-0880-48ef-85e8-23b723a3e943.png "null")

```php
{
  "code": 100,
  "msg": "验证通过",
  "data": "MDU3MjAxxxxxxxxx0MzE1NjYwMA=="
}
```

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102744048-4a19487b-9985-4e94-afd7-c47237fd944e.png "null")

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102744117-9df773fc-763c-4127-a12f-2afc9fafcb07.png "null")

### 支付状态签名复用绕过

此类型绕过方式是我挖到过最奇葩的支付漏洞,我原以为依靠修改支付状态这些漏洞已经绝迹,但仍存在于支付场景中,并且生成业务居多,绕过后就可生成对应凭证,,后端返回不验证前端传来是否真实状态,接收就生成,漏洞只用于技术研究,请各位师傅谨记网络安全法；定位到医院挂号业务

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102744224-63668c30-9a2c-477b-b02b-52a5ed314128.png "null")

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102744279-b2f10500-33d0-429f-a772-136878d7ac5d.png "null")

随意选择科室进行挂号操作,正常支付下单,记录下所有的请求

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102744342-e0e5ae7f-3de0-4dbc-9c7a-fb8ef12b0823.png "null")

定位此关键支付业务接口,付款后直接返回支付成功,并无其他校验字段操作,优先想到可否尝试替换返回包达到支付绕过的效果

```php

https://xxxxxxx/api/bz/order/Sta/appoint

---------------------------------------------------------

{
"code":0,
"message"：“支付成功”，
"data":null
}
```

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102744410-5a1ed981-ae53-4f0d-af93-b2eba1f1ca5a.png "null")

重新再下一个科室订单挂号测试,在支付页面将右上角二维码叉掉,就会走入到验证支付状态接口,但是当我满心欢喜替换过后,订单并未成功绕过,显示还是未支付

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102744477-a5a65cd1-b728-4c65-8adc-b45ea1f373cc.png "null")

冷静思考一下,响应体主体确实并没鉴权字段,那么会不会是响应体携带了某些其他凭证呢,回去观察确实让我发现了一个类似凭证的`id` 好消息是我定位到为什么我替换响应包不能绕过了,坏消息是大概率无法绕过了,如果此参数是跟订单号绑定一起后端返回的话,我就无法突破了

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102744533-19a7bfdf-1de0-4bf4-ba95-347f53722384.png "null")

```php
tlogTraceId: jyvU1094795431411044352
```

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102744597-18cc0fbf-1cd7-4964-8bfe-bc1924dbbe43.png "null")

但是这个时候我有了一个大胆的想法,这个鉴权的签名可不可以复用呢,`JWT`都可以复用,签名当然也可以尝试复用,渗透测试就要脑洞大开,于是我复制整个支付成功的响应包,再次重新下单拦截

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102744477-a5a65cd1-b728-4c65-8adc-b45ea1f373cc.png "null")

叉掉二维码捕获到判断支付状态请求后拦截此请求并全体替换为支付成功的整体数据包,最终显示挂号成功并回显就医凭证二维码,但在订单中无法看到成功,绕过了需要花钱这步,直接生成就医凭证可以直接前往医院排队使用

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102744661-e025c5bf-fd22-4b70-8df8-6ab70f60228c.png "null")

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102744734-f2f79d0c-efc4-4d96-b91f-04a94d68d40b.png "null")

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102744797-8fbe7254-f4a4-44a0-ab5c-ae724a5125a6.png "null")

### 定位鉴权参数绕过生成

通过上方案例我不禁思考难道只有这么明显的返回包才会出现这种问题吗？并不是的,我理解的是生成业务都可能会有某个请求鉴权不完整, 拓展到任意功能点,假设完成整个请求后并无权限校验返回,均可以利用此方式测试,但前提必须要是关键请求的状态码出现！

```php
code:500 ---&gt;  200
statr: 0 ----&gt; 1
data:500-----&gt; null

```

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102744859-5520ede7-62ca-4f24-a9ba-619e60b0740b.png "null")

定位一处景区业务购票选择游玩项目下单

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102744919-59b4c7f1-031c-422e-89e4-be70cbc5698e.png "null")

正常业务流程进行支付下单,并捕获全部数据包,定位到关键支付成功的包

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102745006-792a878e-3258-495f-b7ea-637b265cc9e8.png "null")

当时报告截图不全下图替代,微信付款后,保留下成功支付的返回包,很长的一串返回包,但是我观察到并无明显的鉴权参数,大部分是当前的时间,关于订单信息没有,那么是不是意味着定位到鉴权字段又可以尝试绕过生成呢

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102745070-27067249-0a20-40ae-9e34-c954071c0558.png "null")

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102745130-1d067b36-17ee-4384-8217-ced468d84a8c.png "null")

通过仔细定位参数,测试得出是由三个状态码参数控制后端出票结果,那么拦截修改返回包,2个参数为1,1个参数为0

```php
修改3个参数,修改前错误的,修改后是正确的

tyep:1-----&gt;0  
status:0-----&gt;1
status:0-----&gt;1

```

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102745187-ffaec0c4-5edd-4e07-a00f-09aba6ef36e2.png "null")

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102745258-f7a25f86-4b5c-4572-bcb8-3ac6e59a6ef2.png "null")

修改完成后放包,后端返回不验证前端传来是否真实状态,导致直接生成票据,导致实现真正意义上的0元购！一分不付完成购买

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102745321-65b5158e-9938-47f1-a5a0-ca992ec0495c.png "null")

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102745381-137e656c-db11-49f7-b251-f74293ad6635.png "null")

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102745457-87b8875f-4ba8-4a6d-8bd1-1d64983ae283.png "null")

### 状态码的攻击面

漏洞挖掘中如果想要在众多白帽子中脱颖而出,无非自身具备独家的思路,这种思路只有自己知道,要么是可以测试到其他白帽子测试不了的资产,也就是更多的功能点,更多的攻击面,信息收集手法大同小异,但大部分资产也是需要特定的权限账号才可以进入测试,有其他师傅也分享过此方法,我属于加深再复刻一次,并不只有登录框可以操作,存在权限控制的点都可以利用状态码尝试一二

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102745539-2c11e54e-e37a-4592-a294-0b0d14cbab36.png "null")

- - - - - -

这类场景相信很多师傅都遇到过,只能提交真实信息才能进入下一步并且不能跳过,如果有真实信息自然好但是大多数肯定是没有的,那么可以尝试提交虚假信息观察响应包返回情况判断是否可以绕过步骤

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102745602-56bde6d2-f0ce-42e1-aa31-72553fb2632f.png "null")

错误情况下是如下返回包,但是存在多个字段如果不知道真实的响应成功字段盲目修改很多概率是失败的

```php
{
"success"：false,
"code"：“A000200”，
“message”：“无记录”，
“msg”：“无记录”，
“data":null
}
```

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102745672-9f334891-a209-4160-a631-e39a7d1ec5c0.png "null")

我们这个时候可以回到其他业务,到处点点点触接口请求响应,而后在`BP`记录中拿到其他接口响应成功的反馈信息,若字段相近便可尝试替换,看看是否可以绕过,下面数据体是找到的其他接口返回正确字段

```php
{
"success":true,
"code":"A00000",
"message":"成功",
"msg":"成功",
"data":true
}
```

那么重复提交虚假信息再次尝试下一步并拦截响应包,替换为正确字段

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102745799-103fd9b6-80bd-48d3-af43-3d978289463c.png "null")

成功绕过验证情况,进入其他门店信息功能点,那么这个时候又有新的攻击面又可以测试新的未授权

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102745896-0f645021-5bdb-46b7-91bc-8619c4322d9e.png "null")

查询其他门店信息等等或信息泄露,但是此案例危害不是很大厂商给予忽略但也只是由于这个站不够敏感,如果是更为敏感的站点能利用此方法绕过短暂进入后台那么肯定又不一样,拼接接口尝试进入是会有接口鉴权的,只能通过修改响应方式欺骗前后端进入

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102746280-7a2a83d1-452c-45c5-8b7f-17825ec5f7b5.png "null")

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102746504-b2d1fcf9-91a8-40d1-85c4-34a582bcce56.png "null")

![](https://cdn.nlark.com/yuque/0/2025/png/22621815/1756102746568-e48f59fb-1082-47dc-abd7-895096399052.png "null")

### 结语

关于`0`元购支付漏洞手法还有非常多,漏洞挖掘中加以复盘总结,多思路业务场景思路相信各位师傅也能挖掘出更具危害的漏洞,如文章看的开心对各位有一丝丝启发希望点点推荐后续写出更优质文章,交流学习联系V: yueL\_one

发表于 2025-09-12 10:03:23
阅读 ( 3479 )
分类：渗透测试

3 条评论

好靶场 2025-09-14 22:22

感谢大佬分享思路。我们团队这边按照您的思路制作了对应的靶场。如果有哪里没有还远，还请您指点指点 http://www.loveli.com.cn:12531/see_bug_one?id=208 http://www.loveli.com.cn:12531/see_bug_one?id=209 http://www.loveli.com.cn:12531/see_bug_one?id=210 http://www.loveli.com.cn:12531/see_bug_one?id=211

c铃儿响叮当 2025-09-13 19:36

登录接口能不能用此方法

一天要喝八杯水回复 c铃儿响叮当

看业务场景哦，但我一般这种测的比较少大部分都是尝试直接提取JS 接口测试，不行再尝试其他手段

2025-10-21 00:33
回复