(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

使用要重置账户,发送验证码

使用自己已注册手机获得的验证码,去重置目标用户的密码

  • 12
    点赞
  • 62
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

黑色地带(崛起)

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值