WEB安全

逻辑让我崩溃之验证码姿势分享

## 0x00 日常BB
看论坛里大家平时发的技术文章,就知道自己是个还没踏进门槛的小学生,根本不在一个level,有点慌了。还是把自己平时发现的,自认为有点意思的点罗列出来,班门弄斧,师傅们别笑话→.→
## 0x01 前言
本次分享的是自己关于自己遇到的一些关于图形验证码的案例,可能涉及图形验证码、短信验证码等,还是没有将问题探究到多深入,希望文中的思路能有所用。
## 0x02 喂!你的那个验证码暴露了?
### 案例前情有些开发人员在做图形验证码校验这一功能时,可能用到了类似这样的思路,所以出了问题,我不妨大胆臆想一下他们的“直男”逻辑,如下所示,那么问题就出在了验证的环节。

生成图形验证码之后,session中保存了四位验证码信息,通过GET请求获取图形验证码时,直接在验证码的末附上了session中的图形验证码值,用户传参后直接比较,同时也省去了提交之后校验的环节。

### 案例分享

登陆页面很直观的需要图形验证码,输入的信息均正确,就可以成功通过验证,进行登陆。那么,针对图形验证码的请求,有必要仔细瞅他一眼。

ok,在正常不过的一个请求,那瞅一眼返回信息看看,文末有彩蛋,json部分包括了captcha的值,那么字面意思可以是图形验证码的内容了,核实一下之后可以确信了。


所以这个点的问题很有可能基本上符合我上面的流程中对验证环节的臆想,剩下的就可以是绕过或者直接爆破了,因为图形验证码已经over time。

## 0x03 喂!穿上马甲照样认识你!

### 前情提要
上一个案例涉及到了逻辑上存在问题的验证方式,同时很明显的展示了问题存在的点,这一部分没有明显的让你发现验证码的脆弱点,为了规避掉存在问题的点,自以为是用到了常见的拼凑、混淆方式。
### 案例分享
近乎同样的功能点,这个功能点试图使用图形验证码限制短信验证码的请求频率,那么也来看一下他的请求,是否可以从中get一些有用的信息。
PS:这个请求我们可以看到有一个参数_captcha_bankcoas_key=,这个值怎么看都像是用了base64编码,当然不排除是加密算法加密之后再次使用base64进行编码,尝试先进行base64解码看看如何,毕竟参数的定义方式已经告诉你:“这个参数和captcha有关”,来吧,试试看。

返回包中的黄色箭头部分为密文形式,原密文如下:

首先进行一次base64解码,解码后的内容可以看出,好像这个串是通过一部分加密之后,再拼凑一部分再加密的方式,最后一个“#”号到结尾部分看起来就像是先base64的那部分,摘出来解解看:

最后一个“#”号到结尾的部分再次进行base64解密:


再次base64解码之后得到一个密文串儿,怎么看都得是32位md5加密值,图形验证码是6位纯数字,md5在线解密来看,嗯~真香。



## 0x04 喂!验证码我说了算?
### 前情提要
这个案例的与众不同点在于要求你输入红色标记的几个数字,这种验证方式一定程度上应该是很有效果的达到了验证码的作用,但是如果获取验证码的请求中有任何用户可控的数据提交,可能验证码就不是当年的验证码了。### 案例分享这个分享的案例有一个奇怪的逻辑,在做一笔交易时,需要动过动态手机验证码验证的方式进行,获取短信验证码需要图形验证码进行校验。
But,无论这个图形验证码存在的目的是什么,获取图形验证码的请求中有一个参数recAccount是图形验证码的内容部分,那我可就……直接把内容改成1234试试水。


修改过的recAccount到页面之后,验证码也就成了我修改后的1234,不用打码,直接自己愿意什么内容就是什么内容了。

每一笔交易也自然都可以顺利的无视图形验证码的限制了。

## 0x05 容我再想想
em……我突然想到,上面的案例中涉及的场景都是可以通过脚本来自动化的,但是如果在没有写脚本的情况下,能不能利用Bp现有的功能或插件来直接用,案例中的情况可以考虑通过插件Extractor和Bp自带的Marco的方式来结合使用,这样可以将bp指定范围内的请求均经过处理进行自动化的测试或者半自动化的测试。

(1)

本文由来源 先知,由 SecJack 整理编辑!

热评文章

发表评论