凌晨两点，手机我盯着Burp Suite的验证界面，手指在键盘上敲下最后一个payload。码爆目标是破漏一个电商平台的找回密码接口，手机验证码是手机四位数字。理论上，验证爆破空间只有一万种组合，码爆但对方设置了五分钟内五次失败就锁定账号的破漏机制——这本来应该是道铜墙铁壁。

然后我发现，手机验证码校验逻辑放在前端JavaScript里。验证服务器只负责比对用户输入的码爆验证码和session中存储的值，而session值，破漏居然是手机手机号后四位加上固定盐。这等于把保险柜钥匙贴在柜门上。验证我随手改了前端代码里的码爆校验函数，把它变成永远返回true的函数，然后直接提交任意四位数字——服务器居然笑了，放我进去了。

这个漏洞的本质不是验证码太短，而是开发者信任了不该信任的东西。他们把安全决策交给了客户端，而客户端是攻击者完全可控的。类似的问题我见过太多次：有的系统把验证码明文返回在响应头里，有的把验证码直接写在图片的alt属性里，最离谱的是某个银行App，验证码就是固定数字8888，仅供体验用，结果生产环境忘了改。

爆破漏洞的高发区通常在三个地方：短信接口、登录接口、找回密码接口。短信接口容易被刷量，攻击者用脚本循环触发发送验证码，把运营商通道打爆，顺便拖垮服务器。登录接口和找回密码接口则是爆破的重灾区，尤其是那些没有锁定策略、没有图形验证码、没有IP频控的老系统。

有一次测试某政务网站，验证码只有四位数字，且发送后十分钟内有效。我写了个简单脚本，每秒尝试二十次，理论上八分钟能跑完一万种组合。但运行到第三分钟，系统就返回了“操作太频繁”的提示——我以为是撞上频控了，细看才发现，它只是把按钮置灰了，前端限制，后端根本没管。我直接绕过前端，继续跑，十分钟内成功拿到管理员手机号对应的验证码。

这事有意思的地方在于，很多开发者的安全意识停留在“看起来安全”的层面。他们知道验证码要有时效性，知道位数不能太少，却忽略了爆破的根本防御——服务端要限制尝试次数，而且要限制得足够狠。比如连续错误三次就锁定账号十五分钟，或者同一个IP一天内最多尝试五十次，再或者引入滑动验证码作为前置门槛。这些措施单独拎出来都不完美，但叠加起来，爆破的成本就会高到让攻击者觉得不值。

手机验证码爆破漏洞之所以长期存在，还有一个现实原因：业务部门催得紧。产品经理说“短信验证码登录必须三秒内发出”，开发就省去了图形验证码的步骤；运营说“用户找回密码流程要简洁”，于是把验证码有效期延长到十五分钟。安全需求往往被当成业务效率的绊脚石，直到出事才想起来补。

我见过最讽刺的修复方案，是某个厂商把验证码从四位升级到六位，然后跟我说“这下安全了”。六位确实把爆破空间扩大了一百倍，但如果没有频控和锁定，一万次和一百万次的区别，只是让脚本多跑几分钟而已。真正的修复应该是：服务端记录手机号维度的失败次数，超过阈值直接拒绝服务，并且每次校验失败后，让旧的验证码立即失效。再配合IP维度的限速，基本就能堵死这条路。

写这段文字的时候，我又想起那个电商平台。他们后来修复了漏洞，把校验逻辑移到后端，加了频控和锁定。但没过半年，同一个接口又出了新问题——验证码发送接口被用来轰炸用户手机，一天能发几百条。你看，漏洞就像打地鼠，你按下一个，另一个冒出来。安全不是一劳永逸的事，它更像一场永不停歇的攻防拉锯战，而你永远不知道下一个突破口在哪个不起眼的角落。