记录挖洞踩坑，一次请求试100个密码，数组注入绕过爆破防护的骚操作

原创

是老A
是老A

老A搞安全

2026年7月20日 06:28
贵州

在小说阅读器读本章

去阅读

一位深耕网络安全的老兵，目前是一家安全公司的技术分管，擅长渗透测试及安全培训方向，老A的愿望是大家没烦恼，一切顺心！

某次测试一个登录接口（数据已脱敏，仅供技术交流）

后端代码的逻辑大致是这样的：

接收password字段，判断类型：

• 如果是字符串：直接比对

• 如果是数组：遍历数组，逐一比对，只要有一个匹配就登录成功

也就是说：

// 正常请求{\"username\":\"admin\",\"password\":\"123456\"}// 数组注入请求{\"username\":\"admin\",\"password\":[\"123456\",\"password\",\"qwerty\",\"admin123\",...]}

一次请求，试了100个密码

而且更致命的是，防爆破计数是按请求次数累加的

你一次请求塞了100个密码，系统只记了1次尝试

防爆破系统：\"他只在第3秒发了1次请求，没问题啊“

实际：100个密码已经试完了

这个漏洞的杀伤力有多大？

假设防爆破策略是：5次错误锁定账号。

正常爆破：

第1次请求 → 失败 → 计数1第2次请求 → 失败 → 计数2第3次请求 → 失败 → 计数3第4次请求 → 失败 → 计数4第5次请求 → 失败 → 计数5 → 账号锁定

5次请求，只能试5个密码

数组注入爆破：

第1次请求 → 塞100个密码 → 全部比对 → 计数1第2次请求 → 再塞100个密码 → 全部比对 → 计数2第3次请求 → 再塞100个密码 → 全部比对 → 计数3第4次请求 → 再塞100个密码 → 全部比对 → 计数4第5次请求 → 再塞100个密码 → 全部比对 → 计数5 → 账号锁定

5次请求，试了500个密码

而且如果密码在第100个命中了，只需要1次请求就进去了，防爆破根本来不及反应

为什么会出现这种漏洞？

核心原因：前后端数据模型不一致

前端的登录表单里，密码输入框是一个字符串类型：

<input type=\"password\" name=\"password\">

正常浏览器发出的请求：

password=123456

后端接收的时候，PHP/Java/Python等语言会把它解析为字符串

但攻击者不通过浏览器发请求，而是用Burp Suite直接改JSON包：

{\"username\":\"admin\",\"password\":[\"123456\",\"password\",\"qwerty\"]}

后端如果是强类型语言（如Java SpringBoot），会直接报错

但如果后端用的是弱类型语言（如PHP、Node.js、Python），或者框架做了自动类型转换，可能就会默默接受数组，然后遍历它

这不仅仅是登录接口的问题

同样的思路，可以迁移到很多场景：

场景一：批量ID查询

正常请求：

GET /api/user?userId=1001

攻击请求：

GET /api/user?userId[]=1001&userId[]=1002&userId[]=1003

场景二：角色越权

正常请求：

{\"role\":\"user\"}

攻击请求：

{\"role\":[\"user\",\"admin\",\"super_admin\"]}

场景三：多个条件组合

正常请求：

{\"condition\":\"id>0\"}

攻击请求：

{\"condition\":[\"id>0\",\"1=1\"]}

怎么测试这种漏洞？

第一步：抓取登录请求

用Burp Suite拦截登录请求，把请求体改成JSON格式

第二步：修改password字段类型

把\"password\":\"123456\"改成\"password\":[\"123456\",\"password\",\"admin123\"]

第三步：发送请求，观察返回

如果登录成功 → 存在数组注入漏洞

如果返回400/报错 → 后端做了类型校验，没戏

第四步：如果成功了，批量扩充密码字典

把常用的弱密码字典塞进去，一次请求试几百个

常用的弱密码字典：

123456, password, admin, 12345678, qwerty, 123456789, 12345, 1234, 111111, 1234567, 000000, admin123, abc123, test, root, 123123, 666666, 888888, passw0rd, 1qaz2wsx, qwerty123, admin@123, ...

这个漏洞本质上是一个类型安全问题

开发者的错误在于：信任了前端传来的数据格式

⚠️ 法律声明：以上内容仅供安全学习和授权测试使用。未经授权的漏洞利用属于违法行为，请勿对未经授权的目标进行测试