验证码这玩意儿，证码本来是绕过用来挡机器人的。结果有些验证码，证码连机器人都懒得挡，绕过自己先躺平了。证码

前阵子帮朋友看一个后台系统，绕过登录页面弹出来一个验证码输入框，证码上面四个歪歪扭扭的绕过数字。我随手填了“1234”，证码居然进去了。绕过又试了一次，证码还是绕过“1234”，又进去了。证码朋友在旁边看着，绕过说这系统用了三年，证码没人发现这个问题。

这就是典型的“pikachu验证码”——名字是我自己起的，取的是皮卡丘那个“皮”字，意思是这验证码纯粹是个摆设，皮一下很开心，但一点用没有。它的核心问题不在于图形识别难度低，而在于整个验证逻辑就是错的。

它到底怎么绕过的

正常的验证码流程是这样的：服务端生成一个随机串，存进session，把图发给前端；用户填完提交，服务端拿用户输入和session里存的比对，一致就放行，不一致就打回。关键点在于——比对发生在服务端，而且session里的值用完就销毁。

pikachu验证码的毛病出在哪？我抓包看了下那个后台系统的请求。前端提交登录表单时，验证码字段确实带上去了，但服务端根本没拿它跟session比对。换句话说，那个输入框就是个装饰，你填什么都行，填“皮卡丘”也能过。更离谱的是，有些系统把验证码的正确答案直接写在前端JS里，或者放在响应头的某个字段里，抓个包就看到了。

还有一种情况更常见：验证码虽然比对了，但session里的值永远不刷新。你第一次请求拿到验证码“8F3K”，提交时填对了一次，之后这个session里的值一直是“8F3K”，直到session过期。攻击者只要手动过一次验证码，后面就能无限次复用同一个答案跑字典。这等于给暴力破解开了个后门，还是带迎宾地毯的那种。

为什么这种问题一抓一大把

我翻过几个开源CMS的登录模块，发现验证码这块的代码质量普遍堪忧。有的开发者图省事，直接在控制器里写个if($code != $_SESSION['code'])就完事了，连大小写都不区分，更别提防重放。还有的把验证码生成逻辑放在前端，用canvas画几个数字，然后前端自己校验——这不叫验证码，这叫自欺欺人。

更隐蔽的一种是“验证码接口不设限”。生成验证码的接口没有任何频率控制，攻击者可以每秒请求几千次，拿到大量验证码样本去训练OCR模型。等模型训好了，再回头打你的登录接口，识别率能到90%以上。你这边还以为验证码在正常工作，其实早被薅秃了。

怎么判断你遇到的验证码是不是皮卡丘

几个简单的测试方法。第一，填错一次验证码，看返回的提示信息里有没有泄露正确答案或者sessionID。第二，连续提交同一个验证码值，看服务端是否一直放行。第三，用同一个session反复请求验证码图片，看内容是否变化。第四，直接删掉验证码字段提交，看能不能过。这四个测试里只要有一个中了，这验证码基本就是废的。

我见过最离谱的一个案例，某电商后台的验证码是前端用Math.random()生成一个四位数，然后跟用户输入比对。你打开控制台看一眼源码就知道答案了。这种设计思路，大概是把安全当成了“只要我看不见问题，问题就不存在”。

验证码绕过不是什么高深的技术，它暴露的是开发过程中对安全边界的漠视。一个正确的验证码实现，代码量不会超过二十行，但就是这二十行，很多人宁愿复制粘贴一段十年前的老代码，也不愿意花十分钟想清楚它的逻辑闭环在哪。皮卡丘很可爱，但登录页上的皮卡丘，还是早点换掉比较好。