挖掘一 参数添加的注册管理员操作

某证书站存在逻辑缺陷，用户注册时可通过添加高权限role\_id实现管理操作——

访问：

这里提供两种登录方式——

![图片](/media/202609/cef5c9492e2249ce847353357be95fec6605.png)

注意到这里有注册接口，访问page：

![图片](/media/202609/cc0b869bb0d24576a892cdb0a8681f302960.png)

填写好信息，提交注册：

![图片](/media/202609/3b3652f686ca4706a6ef74648613ae494990.png)

随后在BP历史中找到这样一个包：

![](/media/202609/92abb174e5e34ab5a8540cfb2940d8978508.png)

如果注册成功，返回包会返回token，并且在role\_list参数的返回值显示当前角色id。

比如我这里"role":\[1501,1502,1503\] 对应返回包会显示role\_list":\[1501,1502,1503\]

这里观察有role字样，一开始想到它的带管理员的权限可能是1，于是直接在这个api中新增了一个信息填写：

![](/media/202609/9a00655b15a3484681fe3026ea2229226901.png)
把原本的id改成 1 ，但是返回包的role\_role中没有返回1，说明在这个id值不存在。

但是依旧可以注册成功，也返回了token。

![图片](/media/202609/da9926ed7fb84996b3bb4c07261372352240.png)

进行登录和使用api也是ok的。

![图片](/media/202609/bf875e26142f4ddb81009080178d1a681359.png)

然后进行登陆的时候，发现登陆是普通账号，因为role=1这个值根本不存在，并且不是管理员权限。

因为role=1没有匹配上这个系统的管理员，登陆后，然后又在历史包中找了一会，找到另一个数据包：

![](/media/202609/475dad05694d4959bff19e7d4b7158427239.png)

这里发现，发送包携带的rid都是存在的权限角色，如果存在的话，后端返回包，会返回这个rid的值。如果发送包携带的rid不存在，后端就会报错。

![图片](/media/202609/262846c0fe2744498f211d02c7940bd84614.png)

这里也是通过回显观察，得知存在哪些rid，我这里把原本的id 1503 改成 1，发现直接报错。

![图片](/media/202609/2b3a1dd1d61e44d390804df3beef73583920.png)

改成1507也是报错。

![图片](/media/202609/92214bf3e58948e8aa973eb2688b1c1d9878.png)

逆序遍历：

![图片](/media/202609/445b914171994be2892a6e48ce388ea74138.png)

成功发现存在一个新的权限角色id为1499

![图片](/media/202609/64be4c3086464ceca8a1ba5e6ba155ca5467.png)

重新注册，POST /api/account/signup：

输入新发现的id。

![图片](/media/202609/8f8ae7bfb67b45cc9b48d1a0d0b2050e9076.png)

可以发现这里是返回了我们想要的rid的，果断登录：

发现新账号变成了管理员权限。

![图片](/media/202609/da0316a003f442da8d871fe9757c1f277307.png)

这个利用在于要用极少数测试phone在注册接口完成role\_id赋值，其后台没有对其检验，通过组合其他api得到真实的管理role\_id。

挖掘二 资源消耗占用统一认证次数

资源导入引起的耗尽攻击：

一个统一认证代码应该最多只能被认证5~10次，但是攻击者可以通过重复发包，恶意占用认证次数，导致受害者企业无法注册该平台。

![图片](/media/202609/56d9965fb28b4e0f9f337e41f8ae5e997094.png)

通过爱企查找到一个统一企业代码：91xxxxxxxxx

![图片](/media/202609/fbf981451e6e437d8686861efcbfd6045317.png)

![图片](/media/202609/f62364c5623f4eceb252f45c9d1870c08131.png)

进行认证绑定，输入爱企查找到的企业统一认证代码。

发现可以绑定成功一次。

![图片](/media/202609/ebee4e435a534a20b30def157a2099892973.png)

{"quaxxxx\_code":"913xxxxxxxxH"} 继续重放至5次，后面提示报错了。

![图片](/media/202609/589242cc22fd4c17bcd45eade8ce38b28215.png)

提示这个信用代码提交已上限

![图片](/media/202609/fb2e748903ef4789978e08efba3d25b86968.png)

现在要证明的是后端的“锁”不止是针对当前用户的，而且这个整个统一认证代码都无法被绑定了，直接被全部占用了，再找一个账号登进去，用刚才的企业整个统一认证代码尝试—

都提示无法使用刚才的统一认证代码。

![图片](/media/202609/47dd680925f14a939113c587e06d48536125.png)

已构成资质代码滥用/占用；这里提示“明天再试”，交的时候并没有一直测试，实际这类问题可以多请求，比如一周都去请求完，看是否达到预设阈值后，永久不能使用统一认证代码。

不知道是不是交多不友好，只给了低危，也是一笔小赏金。

![图片](/media/202609/742b635f74004676a0d8f92ab932bd3d3188.png)

挖掘三： 小程序存储桶任意文件删除

访问一个公众号小程序，点击我要报修。

![图片](/media/202609/7e0e6cb56eb94f86bb76a93922dcabbe5794.png)

点头像这里，可以抓捕得到img地址：

![图片](/media/202609/72bc4112b03841b6b90fa5ddef2139955890.png)

发现返回包地址，是个人头像地址。

![图片](/media/202609/91a503eadbdb4734bcf13ad52ea2cc922696.png)

用浏览器去访问url，可以看到头像图片。

![图片](/media/202609/44552d73887240d0b42a03e8dd2e5aa92939.png)

刷新页面，获取这个请求存储桶图片的数据包。

![图片](/media/202609/1830284022a640f0b1e7115634af4b2e3742.png)

这里存在DELETE操作，发现可以直接删除这个图像。

通过这个方法，burpsuite抓包到的本小程序的任意图片，都可以随意删除。

![图片](/media/202609/070ba69e4436405dac0f1b4aef533e004534.png)

浏览器访问这个原版图片的url，提示文件已经没了。

![图片](/media/202609/f5ab0363f8b6415885e2ca6bd622b4828332.png)

挖掘四：严重的敏感信息泄露。

某xxx小程序存在严重敏感信息泄露——

家长身份登录后，在绑定学生前，这里跳出很多学校——

![图片](/media/202609/28f52e291dbb429b977fd97de6a5fa436781.png)

这些学校都是可以去勾选角色的，这里选一个

![图片](/media/202609/edba7507c32e47779f71469928c83da41849.png)

抓取“提交“报文：

发现这里泄露了学生的id、学生的姓名，当然这里危害不大。

![图片](/media/202609/47d0c853a786446292151e54ac166c0c3464.png)

这里绑定学生后，再去点击查看学生信息，发现泄露了SFZ和学号——

数据包：

可以通过修改stu\_id，遍历出其他学生SFZ信息，这个就危害极大了，可以全部查看。并且信息比较详细，赶紧提交到src平台。

![图片](/media/202609/cd012634ffa641ba99ee78edffe00de34696.png)

这个国网学籍号=SFZ。通过URL访问，还可以可以获取个人照片。

![图片](/media/202609/79cc3d5f39fc4537964cb2a4f2269c754077.png)

以上漏洞均已经提交并且修复，请勿尝试复现。

越权管理到信息泄露