某次渗透测试，验证目标系统是码绕某政务平台的密码重置模块。我提交了一个并不存在的过漏手机号，系统返回“用户不存在”。验证换成正确手机号，码绕验证码发送成功，过漏但响应包里的验证`code`字段赫然写着`123456`——明文躺在那里，连加密都懒得做。码绕

这不是过漏孤例。验证码绕过漏洞的验证根源往往不是单一缺陷，而是码绕逻辑链上的某个环节偷了懒。开发人员默认“客户端发来的过漏请求可信”，于是验证验证码校验只存在于前端JS里。用Burp Suite拦截响应，码绕把`"success":false`改成`true`，过漏直接放行。更蠢的是有些系统把验证码存在cookie里，清空cookie或改成`null`，后端反而跳过校验——因为代码写的是`if(cookie != null){ checkCode(); }`。

另一种常见姿势是并发绕过。验证码有效期通常5分钟，但后端没限制尝试次数。我写个脚本每秒跑500次，四位数字验证码的10000种组合，20秒内穷举完毕。有的系统做了图形滑块，可滑块轨迹是前端生成的，重放一次旧轨迹就能通过。最讽刺的是，某些验证码本身就是为了防机器人，结果后端把“是否通过验证”的状态存在session里，而session ID是固定的——那还验证个什么劲？

还有个经典案例：某电商App的短信轰炸接口。验证码发送后，服务器只在内存里存了5分钟内的发送次数，但没绑定IP和设备指纹。我换几个UA头，伪造X-Forwarded-For，瞬间刷出几十条短信。这不算严格意义上的验证码绕过，但暴露了同一类思维漏洞——信任不该信任的输入。

说点实际的修补思路。第一，验证码校验必须放在服务端，且校验逻辑不能依赖前端传参。第二，限制尝试次数和频率，用Redis做原子计数，超过5次直接锁定账号15分钟。第三，把验证码和用户身份、会话ID强绑定，每次请求都校验这三者的匹配关系。第四，别把验证码直接回显在响应里——见过太多因为调试接口忘了删导致的低级失误。

最后说个反直觉的观察：很多系统加了短信验证码后，反而比纯密码登录更脆弱。因为验证码通道缩短了攻击路径，只要绕过它，等于绕过了密码。开发时多问自己一句：“如果攻击者直接篡改请求，我这个逻辑还成立吗？”答案不成立的话，趁早改吧。