分享一个验证码暴力撞库漏洞的案例

记录一个验证码暴力破解的案例，安全问题不容忽视呀。

某公司接到用户反馈，应用存在安全漏洞，通过技术手段可以在无手机情况下，获取验证码，直接修改密码成功。如果用户密码被他人修改成功，直接涉及到资产损失问题，无疑是一个非常严重的漏洞。

通过跟用户交流，他是通过暴力撞库的手段，去匹配正确验证码，由于后端服务没有做次数限制，所以可多次试错，通过程序发送请求，很容易就得到正确的验证码，从而修改用户密码。

---

回过头，看看正常的密码重置流程

• 进入用户手机号登录页面
• 点击「忘记密码」 ，输入手机号
• 接收四位数验证码，填写验证码
• 后端对验证码进行校验
• 校验通过后，设置新密码
• 使用新密码登录账号

漏洞演练

先去注册账号，如果手机号已存在，会提示当前用户已经注册，通过随机生成手机号的方式，去测试是否注册过当前应用，如果已注册，就进入忘记密码页面，通过手机号验证码方式找回账号。

忘记密码页面，输入上面的手机号，点击发送验证码后，后端会下发验证码到该手机号上，这个验证码现在只有两个人知道：

• 手机号主本人
• 后端服务

当然是不可能直接打电话给号主本人要验证码的，所以从后端服务下手。

随便输入四位数验证码，点击重置密码，会发送校验验证码的接口，请求内附带上客户端输入的验证码，抓包该请求，通过人为构造验证码的方式，进行撞库，直到成功。

由于验证码是四位数字，所以范围锁定在 0000～9999 内，不断请求，消耗数字就可以了，直到响应内返回成功的状态及 token 字符串。

将 token 字符串、新密码、手机号作为参数传递给更改密码的接口，请求成功后，密码修改成功。

问题分析

1、接口验证码参数为什么没有加密？

这个验证码参数其实是做了加密处理，但是由于在非常老的历史版本上，使用明文传输，为了兼容，所以在低版本的请求上，通过明文传参后端是正常接收并处理的。

2、验证码校验接口，次数没有限制？

这才是根本原因，用户账号是非常重要和基础的业务，后端在更改密码的接口上没有次数限制和风控，应该在试错 N 次后，直接取消本次验证码校验，直接认为失败。

---

该问题属于安全范畴，日常工作根本不会去注意。这也反映出测试同学在日常工作中，需要通过各种复杂的业务问题，来提高预知风险的能力，丰富项目测试的经验，这才是真正的工作经验。

我认为上述是一个比较好的案例，分享给大家，共同学习。

另外，安利一个好用的接口测试工具 – burp suite。