（36.1）【验证码漏洞专题】验证码复用、无效验证码、未绑定验证码、前端获取、暴力破解、回显……
目录
一、验证码不刷新/复用（固定的）
1.1、原理：
1.2、产生的原因：
1.3、利用过程一：（不刷新验证码）
1.3.1、前提：
1.3.2、获取验证码
1.3.3、利用爆破：
1.4、利用过程二：（报错不关闭）
1.4.1、前提：
1.4.2、获取验证码
1.4.3、利用爆破
二、无效验证
2.1、原理：
2.2、产生原因：
2.3、利用过程：
2.3.1、获取验证码
2.3.2、重新登录
2.3.3、修改
2.3.4、利用
三、验证码未与手机号绑定
3.1、原理：
3.2、产生原因：
3.3、利用
3.3.1、获取验证码
3.3.2、重新登录
3.3.3、修改
3.3.4、利用
四、验证码暴力破解漏洞
4.1、原理：
4.2、产生原因：
4.3、爆破时间效率（纯数字）：
4.3.1、4位
4.3.2、6位
4.4、利用过程：
4.4.1、获取验证码
4.4.2、抓包爆破
4.4.3、分析
4.4.4、目的：
五、客户端验证绕过
5.1、原理：
5.2、产生的原因：
5.3、利用过程：
六、验证码前端可获取
6.1、原理：
6.2、产生原因：
6.3、利用过程一：
6.3.1、直接返回明文验证码
6.3.2、返回密文验证码
6.4、利用过程二：
6.4.1、拦截替换返回包
6.5、利用过程三：
6.5.1、验证码隐藏在源码里
6.6、利用过程四：
6.6.1、验证码隐藏在Cookie中
七、验证码回显
7.1、原理：
7.2、利用原理：
7.3、利用过程：
7.3.1、常规流程：
八、验证码薄弱
8.1、原理：
8.2、产生原因：
8.3、工具：
8.3.1、 PKAV HTTP Fuzzer 1.5.6
8.3.2、GraphicsMagick（Linux）
8.3.3、Tesseract-OCR
8.3.4、xp_CAPTCHA（BP插件）
九、验证码重放（短信轰炸）
9.1、原理：
9.2、产生原因：
9.3、利用过程：
十、墨者靶场：
10.1 登录密码重置漏洞（验证码复用）：
（This message is make for you ）
一、验证码不刷新/复用（固定的）
1.1、原理：
顾名思义，在某种条件下，验证码未被刷新，被恶意利用，或使用后未销毁，被重复利用
1.2、产生的原因：
Session存在有效期
逻辑处理的漏洞，使用后没直接销毁
1.3、利用过程一：（不刷新验证码）
1.3.1、前提：
在Session有效的时间内（即身份凭证没失效）
1.3.2、获取验证码
获取验证码并缓存于Session中（身份凭证）
1.3.3、利用爆破：
使用burpsuite抓包，使用同一个Session，进行登录密码爆破（无论失败多少次，只要不刷新页面就可在销毁前进行有限次爆破）
（但是在有限的时间内穷举爆破可能是很小的）
1.4、利用过程二：（报错不关闭）
1.4.1、前提：
前提还是在Session有效期内
1.4.2、获取验证码
获取验证码并缓存于Session中（身份凭证）
1.4.3、利用爆破
使用burpsuite抓包，使用同一个验证码，进行登录密码爆破
密码错误，系统会打开一个新页面或弹出一个警告窗口，提示用户登录失败
（如果点击确认，会返回登录，且验证码会刷新）
使用burpsuite的intruder模块就可以进行暴力破解就可
二、无效验证
2.1、原理：
存在接口问题，因为每个功能都会被设为不同的模块进行耦合，如果出现验证模块与功能没有没有通过接口关联上，此时2模块不存在如何关联，所以无论输入任何验证码（收到的验证码），都判对（出现几率小，多见于新、小网站）
2.2、产生原因：
开发阶段，出于安全性考虑，将每个功能进行单独开发，后通过接口关联，但是如果由于疏忽导致未进行关联，就会出现验证无效。
2.3、利用过程：
2.3.1、获取验证码
使用自己手机注册（等操作）获取验证码
2.3.2、重新登录
重新进去注册（上面要操作页面）再使用目标手机注册
2.3.3、修改
并使用自己手机获取的验证码
2.3.4、利用
可以进行绑定任意手机号
重置密码
任意用户注册
……
三、验证码未与手机号绑定
3.1、原理：
顾名思义，请求的验证码未与对应的手机号进行绑定
手机A的验证，也可以手机B使用，和上面的有异曲同工之妙
3.2、产生原因：
正常情况，验证码仅能使用一次，验证码未能和请求手机号绑定
验证码因为有一段时间的有效期，会被恶意利用
3.3、利用
3.3.1、获取验证码
使用自己手机注册（等操作）获取验证码
3.3.2、重新登录
重新进去注册（上面要操作页面）再使用目标手机注册
3.3.3、修改
并使用自己手机获取的验证码
3.3.4、利用
可以进行绑定任意手机号
重置密码
任意用户注册
……
四、验证码暴力破解漏洞
4.1、原理：
顾名思义。因为验证一般由4位或6位数字组成，对验证进行枚举爆破，但是要在验证码过期时间内爆破出来才有效。（5分钟或15分钟有效时间，最多w把次）
4.2、产生原因：
服务端未对验证时间、次数作出限制，存在爆破的可能性
短信验证码由4位或6位组成，存在爆破可能性
4.3、爆破时间效率（纯数字）：
4.3.1、4位
从0000~9999，10000种可能，5分钟可以跑完（多线程）
4.3.2、6位
从000000~999999,1000000种可能，是4位验证码的100倍
4.4、利用过程：
4.4.1、获取验证码
输入手机号获取验证码，输入任意短信验证码
4.4.2、抓包爆破
抓请求的数据包，将短信验证码参数设置成有效负载，payloads（有效负载）设置为字数型，多设置几个线程，（根据验证码长度）把取值范围设置为0000-9999，点击开始攻击，进行暴解
4.4.3、分析
对攻击结果进行分析，对返回响应包长度判断，如果有一个和其余的都不一样，就可能是爆破成功了
4.4.4、目的：
这个老六，验证码利用的目的都一样了（任意注册，越权登录……）
五、客户端验证绕过
5.1、原理：
顾名思义，在客户端验证，就创造了修改的机会，并进行验证的绕过
5.2、产生的原因：
未采取安全的验证方式，即在服务端进行验证，当在前端进行验证的时候，就会存在绕过的风
逻辑设计缺陷，可绕过验证，比如直接删除COOKIE或删除验证码参数、验证码参数可绕过、当验证不通过清空session时，验证码参数值为空时绕过、绕过和修改Response状态值等
5.3、利用过程：
验证码这一块，利用目的一模一样呀，根据利用方法略有不同
六、验证码前端可获取
6.1、原理：
顾名思义，如果在前端产生、校验验证码（js），则可以通过抓包查找验证码字段，或关闭js等手段，可能达到最终目的。
（以前的网站中）由于安全意识缺乏，会隐藏在网站的源码中，或者隐藏在请求的Cookie中
6.2、产生原因：
缺乏安全意识（多见于老网站）
6.3、利用过程一：
6.3.1、直接返回明文验证码
点击获取收集验证码，监听到两条json数据，可以发现验证码就藏在ticket里面，输入验证码即可登陆成功
6.3.2、返回密文验证码
验证加密后返回客户端，获取加密后的验证码，解密后即可登录成功
6.4、利用过程二：
6.4.1、拦截替换返回包
①使用正常账号修改密码，获取验证码通过时服务器返回数据
②分析返回数据中成功时的数据
③使用burpsuite代理后，点击确定，服务器会返回验证码错误信息
④使用保存的信息里面的验证成功的数据，进行替换
eg：{"MessageHeader":{"MessageID":"RSP036","ErrorCode":"S000","Description":"成功！"}}
6.5、利用过程三：
6.5.1、验证码隐藏在源码里
①自己提交自己的验证码
②右键打开网站源代码，按Ctrl+F键进行搜索，查找自己提交的验证码进行匹配，如果匹配到，则说明验证码隐藏在源码中
③通过编写脚本代码（python），提取源码中的验证码并将其填入每次请求的报文中，达到各种批量操作目的
6.6、利用过程四：
6.6.1、验证码隐藏在Cookie中
验证码的值可能会用Session存储起来，通过自己提交的验证码，去在Session中寻找到验证码，下次输入错误的验证码，抓包修改。（Session占用服务器资源，有的验证码的值被加密后存储在Cookie中）
在提交登录的时候抓包，分析一下数据包中的Cookie字段，寻找相匹配的验证码，或是经过了简单加密的验证码
七、验证码回显
7.1、原理：
把验证码校验的功能放到客户端来进行（返回数据包中、客户端页面中）,从而导致验证码在客户端回显
7.2、利用原理：
客户端回显，就是当注册或者绑定的时候，用户向网站系统发送一条验证码(短信验证码等)的请求,cookie中会包含验证码并直接回显在数据包中（mobile_code=）
通过抓包工具可截取真实验证码（mobile_code=），并修改自己提交的验证码（code）与真正验证码一致，（在repeater重发器中）并根据返回的状态码（例如0,1,2,3等这样的数字）进行判断
7.3、利用过程：
7.3.1、常规流程：
设置代理拦截-----填写要绑定的手机号-----点击发送验证码-----提交验证码-----客户端回显（重点：抓包修改）
抓包
服务器端向手机发送的验证码在cookie中的"moblie_code="中会有显示
判断正确回显规则
将抓到的回显到客户端的包发到repeater（重发器），然后一般会有特殊的回显数字，判断每种数字代表的含义
修改
填写正确验证码的，在回显的时候，与填写错误的验证码的时候回显的不一样的数字，就是状态码，或者试试修改为正确的回显码
八、验证码薄弱
8.1、原理：
利用工具、脚本，去调用识别图片的API接口，从而达到验证码爆破的目的
8.2、产生原因：
验证码识别简单，无任何干扰，登录时候虽然需要识别验证码，但是验证码设计的过于简单，可以通过工具或脚本来识别识别，进而导致登录面临爆破风险
8.3、工具：
8.3.1、 PKAV HTTP Fuzzer 1.5.6
链接：https://pan.baidu.com/s/1TIPSKyxim67XFL2C0O1lMA?pwd=hj12
提取码：hj12免安装的（win32，win64都可以使用）
8.3.2、GraphicsMagick（Linux）
//①安装相关依赖包
yum install -y gcc libpng libjpeg libpng-devel libjpeg-devel ghostscript libtiff libtiff-devel freetype freetype-devel
//②下载
wget ftp://ftp.graphicsmagick.org/pub/GraphicsMagick/1.3/GraphicsMagick-1.3.25.tar.gz
//③解压
tar -zxvf GraphicsMagick-1.3.25.tar.gz
//④编译安装
cd GraphicsMagick-1.3.25
./configure
make && make install
//⑤验证安装
gm version
输出相关信息就是安装成功了
8.3.3、Tesseract-OCR
（其实都很类似，不做更多操作了）
8.3.4、xp_CAPTCHA（BP插件）
（我在BP的BApp store里没找到）
项目地址（GitHub）：
（初级，白嫖）https://github.com/smxiazi/NEW_xp_CAPTCHA
（接入商用API）https://github.com/smxiazi/xp_CAPTCHA
九、验证码重放（短信轰炸）
9.1、原理：
对短信验证码接口进行重放，导致大量发送恶意短信
9.2、产生原因：
发送验证码的次数、时间限制不严格
9.3、利用过程：
使用目标手机号，每隔60秒可发下一条短信，无限发送，达到短信轰炸的目的
并可通过编写Python脚本，通过计算验证码重复的间间隔，实现短信轰炸的目的
十、墨者靶场：
10.1 登录密码重置漏洞（验证码复用）：
原理：
验证码未与手机号绑定，导致可以通过验证码任意修改任何账号的密码
（这个应该算一个验证码的问题）
无所不能的朝阳市民
目标用户是17101304128
使用已注册的手机，去接收验证码
Wb95eU
使用要重置账户，发送验证码
使用自己已注册手机获得的验证码，去重置目标用户的密码
