文章总结： 本文记录了一次渗透测试中发现的数组注入漏洞，通过将登录接口的password字段从字符串改为数组，一次请求可尝试多个密码，从而绕过基于请求次数的防爆破机制。漏洞根源在于前后端数据模型不一致，后端未对输入类型做严格校验。建议开发者在后端进行类型强制校验，安全测试人员可借此方法评估系统风险。注意：未经授权测试违法。 综合评分： 90 文章分类： 渗透测试,WEB安全,安全开发,漏洞分析,实战经验

记录挖洞踩坑，一次请求试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&nbsp;type="password"&nbsp;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, ...

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

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

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

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：老A搞安全 是老A 是老A《记录挖洞踩坑，一次请求试100个密码，数组注入绕过爆破防护的骚操作》