任意用户密码重置漏洞

凌晨三点，任意黑客论坛上有人贴出一张截图：某电商平台的用户后台管理界面，登录框下方用灰色小字写着“忘记密码”。密码发帖人只花了四步——输入手机号、重置点击获取验证码、漏洞用Burp Suite拦截响应包、任意把返回的用户“验证码错误”改成“验证码正确”——就拿到了管理员权限。评论区一片沸腾：“这漏洞能卖五千刀。密码”

这不是重置什么高深攻击。所谓任意用户密码重置，漏洞本质是任意开发者对“验证身份”这件事偷了懒。正常流程应该层层设卡：验证码要过期、用户要绑定设备、密码要限制尝试次数。重置但很多程序员图省事，漏洞把验证逻辑全压在客户端。你发个请求过去，服务器只回一个“true”或“false”，改个字段就能通关。就像把保险箱钥匙藏在门口地毯下，还贴了张纸条提示方位。

我见过最离谱的案例，是一家银行系理财App。它的密码重置接口居然不校验用户ID是否与手机号匹配——你输入任何人的手机号，再填自己的身份证号，系统就乖乖把新密码发到你手机上。漏洞被发现后，厂商的修复方案是加了个“短信验证码有效期60秒”。可黑客们早就用脚本批量跑接口，60秒足够重置上千个账号。

更讽刺的是，这类漏洞往往出现在“安全投入最大”的金融和政务系统里。为什么？因为这些项目喜欢堆砌复杂的加密算法、买昂贵的防火墙，却忽略了最基础的逻辑漏洞。防火墙挡得住外部扫描，挡不住你自家接口逻辑像漏勺。有个甲方技术主管跟我抱怨：“我们代码审计请了三个第三方团队，结果人家报告里全是SQL注入和XSS，没人检查过密码重置流程。”——因为检查这个不赚钱，审计公司都挑好交差的写。

攻击者最爱的其实是“响应不一致”漏洞。比如某社交平台，你输入不存在的手机号，它提示“用户不存在”；输入存在的手机号，它提示“验证码已发送”。就凭这一句话的差别，黑客就能批量枚举出所有注册用户。再配合短信轰炸接口，把验证码流量打满，逼用户忽略真正的重置短信，然后趁乱用暴力破解猜那四位数字——很多平台验证码根本没尝试次数限制。

修复这类漏洞难吗？不难。把验证码改成六位、增加尝试锁定、强制校验用户绑定关系、服务端不信任任何前端参数——这些都是教科书级别的操作。但现实是，很多公司直到被薅秃了才想起补丁。去年某打车软件被重置了CEO账号，黑客登录后给自己发了张0元打车券，还在个人简介里写了句“下次记得用HTTPS”。事情闹大后，他们CTO在复盘会上说：“我们一直以为漏洞在业务层，没想到在认证层。”

密码重置就像你家门锁的备用钥匙孔。主锁再坚固，备用孔要是拿根铁丝就能捅开，等于没锁。开发者总爱在界面上放“找回密码”按钮，却忘了这按钮背后连着整个用户体系的心脏。说句难听的，百分之八十的同类漏洞，都是因为产品经理没把“安全校验步骤”画进原型图里——他们只关心用户能不能快速找回密码，不关心坏人能不能更快找回别人的密码。

别指望靠用户设置复杂密码来防这种事。攻击者根本不需要知道原密码，他们只需要重置你的密码。而重置的钥匙，往往就藏在开发者随手写的几行校验代码里。那行代码可能注释都没写，但黑客一眼就能认出来——毕竟他们天天研究的就是这种地方。