渗透测试业务逻辑之验证码机制测试

你的名字 2022-05-17 03:18 229阅读 0赞

## **0x00：前言** ##

上周做渗透，有一个 sql 注入，负责安全审核的人给开发说你们的程序既然还有 sql 注入，我一年也看不见几个。这句话让我又再次深刻的认识到，渗透测试常规的一些注入跨站漏洞不如以前那么盛了，有点经验的开发写东西都会去考虑到了，再加上修复方法也在逐渐的完善，逻辑类的东西也应该并重的去测。

## **0x01：分类** ##

我把逻辑类的问题大概总结了一下，大概可以分为十个模块，分别是登录认证模块测试、业务办理模块测试、业务授权访问模块测试、输入 / 输出模块测试、回退模块测试、验证码机制测试、业务数据安全测试、业务流程乱序测试、密码找回模块测试、业务接口调用模块测试。

这次记录的是第六个模块验证码机制测试。

## **0x02：验证码机制** ##

**1，验证码暴力破解测试**

测试方法：只要是有接收验证码的功能都可以测试，发送到任意一个手机号，随便输入验证码，拦截包发送到 intrude，只给验证码加 $，直接使用 burte forcer 把爆破字符设置成 0-9，爆破后根据长度排序即可。

修复方法：设置验证码的失效时间，建议为 180 秒。同时限制单位时间内验证码失败的尝试次数，例如 5 分钟内连续失败 5 次即锁定账号半小时。

**2，验证码重复使用测试**

测试方法：一个提交请求带验证码的功能，输入正确验证码后拦截请求到 repeater，不修改验证码，修改其他参数信息，看是否可以重复提交，如果重复提交成功，则存在此问题。发生此问题的原因是验证码认证成功后没有将 session 及时清空，这会导致验证码首次认证成功后可重复使用。

修复方法：建议验证码认证成功后，服务端清空认证成功的 session，防止有效验证码重复使用。

**3，验证码客户端回显测试**

测试方法：例如找回密码功能，输入手机号和相关信息后，服务器给手机号发送短信，这时候可以通过 f12 查看 response 返回的信息中是否包含验证码，如果包含则存在此问题。造成此问题的原因是验证码在客户端生成的而非服务端。

经验之谈：有人认为谁会在客户端生成验证码，这个问题并非不可思议，我测试的过程中碰到过很多次。测试的时候可以通过 burp 来查看，burp 的 target 栏有请求的历史记录，找到那个获取验证码的 url，在 response 中查看即可，比浏览器 f12 更方便。

修复方法：建议就是不要在客户端生成，要在服务端生成。同时设置其时效性，例如 180 秒，随机生成且一次有效。

**4，验证码绕过测试**

测试方法：例如一个注册功能，输入一个牛点的手机号，随便输入一个验证码，发送给服务器，然后拦截服务器返回的信息，在 forward 前右键选择 Do intercept 下的 Response to this request，然后再放行，这时服务器会返回响应信息，一般会有状态码，例如 0 代表成功，1 代表失败，把返回的结果码改成 0，再放行，成功注册则存在此问题。

修复方法：建议在服务端进行验证码校验时，对客户端提交的验证码进行二次校验。

**5, 验证码识别测试**

测试方法：直接拿工具识别就行，可以用 pkav http fuzzer，这个一般个人感觉没有测试的必要，在测试的过程中，可以让其加固的时候设置下登录失败的次数等策略，验证码可以不加。

修复方法：单对验证码可识别的情况，修复时，可以增加背景的干扰，例如背景色、背景字幕等。字符的字体进行扭曲，粘连，也可以使用公式、逻辑验证方法等作为验证码，也可以使用选择联系人头像、购买过的物品为验证码。

## **0x03：总结** ##

这篇记录了验证码机制模块的测试方法，后续会继续进行其他模块的总结。

--------------------

**                                                                       公众号推荐：aFa攻防实验室**

**分享关于信息搜集、Web安全、内网安全、代码审计、红蓝对抗、Java、Python等方面的东西。**

![20191220230427373.jpg][]

[20191220230427373.jpg]: /images/20220517/92be7c4e117844d7960285553403d572.png