前言

本文是对一些验证码可能出现的问题的总结。

验证码的种类分析

首先验证码有两种：

1.短信验证码，这种通常出现在一些登录，修改绑定信息等位置处。

2.人机验证码，这种一般是用来防止机器操作和密码爆破的，通常是一些识别文字数字，滑动识别图片等形式出现

人机验证码的安全问题

验证码不变化

有时候输入密码什么的这种界面的验证码，只要输入之后，即使密码错误了也不会变化。

这种情况就可以实现密码爆破了，手动输入密码之后直接爆破就可以了。

以下为某个真实网站的案例

验证码前端回显

这种情况是指验证码会通过数据包发送出去，也就是说我们能够看见我们数据包中发送的验证码。

他的原理是这样的，他会生成一个验证码放在数据包中，然后我们自己再输入一个验证码，当我们输入的验证码跟数据包中的验证码相同时就会通过验证。

字符识别类型验证码识别

burp上有些插件是可以对验证码进行识别的。

但是他有点缺陷：

1.有误判的情况发生

2.只能识别一些图片的数字字母类型验证码

3.爆破的时候如果他在你正确密码的时候识别错了验证码，那么真的挺那啥的。

插件使用captcha-killer

教程我为了避免啰嗦写到另一篇博客中了。

【web安全】验证码识别-burp的captcha-killer-modified插件教程（基于百度接口）（总结一些坑）-CSDN博客

验证码后端验证未销毁

有的验证码是后端验证，但是他因为逻辑上的问题，他的验证码检验完毕之后没有销毁。所以导致了这个验证码虽然会变，但是你用前一次的验证码完全没问题。

所以你在数据包中发送相同格式的数据包，只改变密码不改验证码是可行的。

验证码前端验证

先说一下判断方法：

1.我们可以直接审查页面代码找到

2.但是有的时候他会把一部分给封装起来，封装到其他页面。所以我们可以查看我们访问发送的请求，找那种js后缀的请求，找找有没有关于验证码的请求。

绕过思路

很简单先输入正确的一次，然后抓包就行了。他就是在判断你是验证码错误的话不让你发送，后端基本上不验证，但不绝对。我们抓去了数据包直接发数据包就行了。

短信验证码的安全问题

用自身验证码修改其他用户的信息

首先这种短信验证码大多是放到密码修改，信息绑定的界面的。

那么出现这种安全问题的大部分是密码找回的界面。

首先这种界面我们可以尝试用自己的手机获得验证码，然后再把手机号改成其他手机，这样重置的密码有可能是改的其他手机的验证码。

当然这个逻辑漏洞不一定会有，但是如果遇到这种密码重置跟接收验证码在一个地方的网站可以试一下这个思路。

小案例

使用墨者靶场进行操作。

这个是他的背景。

那么我们来更改这个手机号的密码。

这个界面是手机号跟验证码在同一个界面的，那么我们可以试一下以下思路。

我们先用自己的手机号接收验证码。之后再换成目标手机号。

完成修改他人的信息。

短信验证码前端回显

这类情况呢，是我们发送的数据包中会带有对方手机收到的验证码，这样的话我们直接就能可抓包输入进去就行了。

本地response校验

这个是指我们发送过去验证码之后，他可能是在后端进行校验，校验完毕之后会回复前端一个状态码，可能1是正确，3是错误。

（当然这个不绝对，还是要看他是怎么写的）

所以这样的话我们只需要改一下接收的到response就好了

这里有个抓包的原理

我们用burp抓包时，通常是抓的发出去的数据包，但实际上，burp是默认了不抓返回的数据包，但是他也是可以抓取返回的数据包的，我们修改response的值就是要使用这个功能。

抓返回数据包演示

发送数据包的时候，点这个

那么我们接收的数据包会先发送到burp中，然后被我们修改之后再发送回来。

这个返回的下面会有这种error或者1这种敏感的东西，如果他是根据前端校验的话，就可以成功。

（其实最好的测试方法就是写一个正确的，然后直接把整个正确的复制到错误的状态那里最保险）

跳过验证页面，直达目标页面

很多功能点都是有一个验证码的页面，但是他不止有验证码这个页面。他会发送好几个数据包，那么我们用工具把验证码的数据包给他拦截掉，让他直接跳转目标页面，就可以实现一些直接跳转到重置密码，信息修改，资源下载等页面。

简单验证码爆破

首先呢，短信验证码与人机验证码不同之处在于，短信验证码通常输入错误不会改变，这就导致了一些简单的验证码存在被爆破的可能性。

前提是每次输入短信验证码的时候，他的人机验证码没有，能绕过或者不改变。

第二就是这个验证码不限定输入的次数。

最后就是验证码是纯数字这样的成功率会更加的高。