2.1漏洞的形成

目前大多数的验证码漏洞形成总结起来两点，验证码生成机制或验证机制存在缺陷引发的问题。

2.2通用设计缺陷

2.2.1验证码无效

有验证码功能模块，但验证模块与业务功能没有关联性，即无论输入什么或者不输入验证码都判断验证码正确。

2.2.2验证码由客户端生成、验证

验证码由客户端js生成并且仅仅在客户端用js验证，通过抓包看是否有验证码字段或者是关闭js看能否通过验证。

验证码由前端验证有个最大的特征即是对字母大小写敏感，如pikachu靶场中，输入正确的验证码但是在大小写上输入错误时：（不知道对不对个人看法）

当验证码输入正确，大小写也正确时:

前端进行检测验证码，后端检验用户名和密码，那就表示当你点击Login的时候，用户名和密码正确就能登录成功，验证码就如同虚设，这里输入的验证码要跟图片的一样，先过了前端检测才能抓到数据包，不然前端验证码检测没过他会弹窗，导致数据包无法抓取，也就不能暴力破解抓取到数据包之后，将验证码随意修改，反正发到后端也不会检测：

举例：前端验证码

前端验证码是由前端浏览器生成的验证码，填完验证码后，先检查验证码正确与否，如果正确则向后端发送请求，调用后端接口。但是验证码放在前端，安全性不高

对应代码：

点开div：

举例：

假设我们直接访问重置链接，就可以直接重置密码，但是我们不知道旧密码，只能输入新密码

破解思路：随便输入旧密码，然后去修改返回包和上面的验证码相比，只不过将验证码改成旧密码而已

后端验证码

后端验证码是由后端生成的验证码。当用户打开登录页面后，浏览器会向服务器发送请求并携带生成的令牌tolken，服务器随机生成验证码验证码，并将验证码和tolken的对应关系存储在redis缓冲中，之后会在前端动态的生成一张验证码图片。当用户输入验证码并点击登录的时候，服务器会在redsi缓存中找到该浏览器的tolken对应的验证码，验证验证码是否正确，如果正确，接下来开始比较用户名和密码。

2.2.3验证码有回显

验证码在html中或Cookie中显示，或输出到响应头（responseheaders）的其他字段，可被直接查看。

如图为验证码在cookie中回显：

这里借用freebuf的案例：

在发送短信验证码的接口，有可能在其响应体/响应头中泄漏了验证码。如下案例所示，某教育类APP发送验证码的API接口，在响应体中泄漏了验证码，和客户实际收到的短信验证码一致，攻击者可利用该漏洞实现任意用户登录/注册等操作。

2.2.4验证码重复利用

验证码重复使用，即登陆失败后验证码可以不刷新，仍然使用上一次登陆时的验证码且有效，存在爆破风险。

Eg：填写正确登录信息和验证码然后抓取提交数据包，在burp中的repeater模块中重复多次发送该数据包，回显登录成功等字眼，没有提示验证过期则存在验证码重复利用漏洞。