验证码的应用场景有很多，但相对较多的是用在登录页面、支付页面或敏感信息修改的地方需要输入，有的时候登录页面虽然设置了验证码机制，但是很有可能存在验证码可被绕过的情况，如此一来可能带来用户密码暴力破解或穷举应用系统的用户名信息等风险。下面分析一下验证码可能被绕过的几种情况。
（1）登录页面压根就没有验证码机制，这没什么好说的，去完善验证码机制吧。
（2）登录页面验证码虽然设置了，但是抓包后删除验证码字段名及字段值仍可以发送到服务器，而且服务器还可以正常的返回response，并且可以多次重复发送，这种情况就是服务端完全没有校验，这种错误比较low但是还真的有发现过。
（3）验证码设置了，如果在request中删除了验证码名称或值，或输入错误的验证码后，服务器端的返回信息中的确是会报错，比如会返回一个errorCode=354232的一串值，这个时候尝试发送一遍正确的请求看看正常情况下返回的response是多少，比如是errorCode=000000的话，那么在尝试发送错误验证码的时候截获response，手动把errorCode的值从354232改为00000，看看能不能绕过验证码的校验。这种情况在移动APP测试时发现的比较多一些。
（4）验证码设置了，篡改服务器返回的response后也报错了，并且也没给你篡改类似errorCode的地方和机会，这种情况下是不是就没有办法了。其实还有一种情况，就是探测应用系统是否有用户在使用弱口令的这个问题。比如说一个登录页面，需要用户输入用户名、密码和验证码。开发者在设计程序的时候给出了一个验证码只能使用一次的标准，并且后台校验如果尝试登录失败次数大于5次的时候就锁定用户登录。听起来可能已经做得很互联网很安全了。但是，如果把登录的request抓包下来，发现用户名只是以简单的6位数字进行标示的话，那么用户名的数量无非就是000001~999999个而已，注意，这个时候如果验证码没有做到每用一次就报废的话，那么在A账户错误5次前（被锁定前），使用相同的弱口令+相同的验证码再次切换到其他用户下以尝试是否可登录，这种方式其实是可以探测到用户是不是有在
使用弱口令的。
比如以下的请求方式：每个账户号尝试的次数都没有超过5次，所以每次都不会被锁定。尝试发送的弱口令选取概率相对较高的12345678、11111111、66666666、88888888，然后验证码虽然在页面上只能用一次，但是抓包后却可以反复发送同一个请求。这样就达到了探测是否有用户在是使用弱口令的情况了。
账户号 + 账户密码 +验证码
000001+12345678+2367
000001+11111111+2367
000001+66666666+2367
000001+88888888+2367
000002+12345678+2367
000002+11111111+2367
000002+66666666+2367
000002+88888888+2367
000003+12345678+2367
000003+11111111+2367
000003+66666666+2367
000003+88888888+2367
...
999999+12345678+2367
999999+11111111+2367
999999+66666666+2367
999999+88888888+2367
可能有人会觉得这种情况的攻击成本很高，但请记住如果攻击者有足够多的时间和耐心加上足够好的运气的话，还是可以尝试破解出来的，所以如果发现了这个问题的话最好还是修复一下吧。
附上一些见到的比较个性的验证码校验机制，逐渐添加中
