pikachu~~~验证码绕过（on client & on server）

index

• 基于服务端的验证码绕过（On service）
• 基于客户端的验证码绕过（On client）
• 【客户端可能存在的安全问题】
• 【服务端可能存在的安全问题】

我们要来思考一下，什么是验证码绕过？

首先，我们在哪里会经常使用到验证码？

对咯，在各web网页以及APP的登陆界面，会让我们输入：用户名，密码，验证码这三项。

那绕过？怎么绕过呢？

那比如说，你在软件园，去B8上课，走着走着，哎？这个平时走的路被围上了，在修路，这儿走不了了，你一定要直着走过去吗？那修路的大爷估计就要抽你了。

那你咋办？你一看旁边牌子，此路不通，请绕道而行。那你可以通过一些途径绕过去嘛，是吧。那验证码也是一样的，你同样可以把他绕过去。

既想绕过去他，我们必须要了解一下他的原理，上图。

我们今天着重研究基于客户端和服务端的验证码绕过，实践出真知，让我们开启实验之旅！

基于服务端的验证码绕过（On service）

验证码错误时会报错，但不会过期，session有效期间vcode仍然有效。

思路：

判断验证码在输入错误时是否显示

判断验证码是否有非空错误

判断验证码刷新后是否还能重复利用

输入信息后先抓包

发送到repeater后修改验证码，修改验证码后显示：

删除验证码后显示：

接下来测试验证码是否能重复利用：

刷新页面后重新获取一个验证码，

Repeater不修改验证码，再回去验证，显示验证码错误

输入当前正确的验证码多次发送，显示success,说明验证码存在不过期，可以重复利用。

所以开始暴力破解

由于响应数据的不确定因素，中文在加载字典的时候是乱码，这里为了显示好看，只匹配英文部分，可以使用正则：“LoginId”:"([a-zA-Z0-9_]+)",“NickName”，最终提取的都是英文字符。

基于客户端的验证码绕过（On client）

纸老虎，验证码随意修改不报错，由前端生成且只在前端处理。

思路：

查看源码JS有无问题

判断验证码错误和为空时情况

先看JS，右键查看网页源代码

<label><input type="text" onclick="createCode()" readonly="readonly" id="checkCode" class="unchanged" style="width: 100px" /></label><br />                <label><input class="submit"  name="submit" type="submit" value="Login" /></label>
onclick="createCode()"调用JS生成验证码
           

查看源码，我们发现验证码的生成是在前端中实现的。

验证码错误时，依然显示成功。

验证码并没有什么作用，设置暴力破解方式

在前端中用js来做验证码是不安全的，很容易被绕过。

【客户端可能存在的安全问题】

1、有的网站验证码由本地js生成仅仅在本地用js验证。可以在本地禁用js，用burp把验证字段删除。

2、有的网站把验证码输出到客户端html中，送到客户端Cookie或response headers。

3、有些网站默认不显示验证码，而是在输入错误一定数量之后才需要验证验证码，开发人员可能在Cookie中写入一个标记loginErr，用来记录错误数量，则可以不更新Cookie中的loginErr值反复提交，验证码就不会出现。

【服务端可能存在的安全问题】

1、验证码不过期，没有及时销毁会话导致同一验证码反复可用。攻击者可以在Cookie中带固定的sessionID和固定的验证码字符串。

2、没有对验证码进行非空判断，导致可以直接删除验证码参数。

3、产生的验证码问题有限

Sniper（狙击手模式）：一次只会对一个位置进行攻击

Battering ram（攻城锤模式）：同样情况下，攻击次数减半，每次两个位置用同样的密码

Pitchfork（叉子模式）：可以多组密码本payload，每个都不同

Cluster bomb（炸弹模式）：交叉组合，每一个密码本里的密码都对应于另一密码本所有密码