记录一个验证码暴力破解的案例，安全问题不容忽视呀。
某公司接到用户反馈，应用存在安全漏洞，通过技术手段可以在无手机情况下，获取验证码，直接修改密码成功。如果用户密码被他人修改成功，直接涉及到资产损失问题，无疑是一个非常严重的漏洞。
通过跟用户交流，他是通过暴力撞库的手段，去匹配正确验证码，由于后端服务没有做次数限制，所以可多次试错，通过程序发送请求，很容易就得到正确的验证码，从而修改用户密码。
回过头，看看正常的密码重置流程
进入用户手机号登录页面点击「忘记密码」 ，输入手机号接收四位数验证码，填写验证码后端对验证码进行校验校验通过后，设置新密码使用新密码登录账号漏洞演练
先去注册账号，如果手机号已存在，会提示当前用户已经注册，通过随机生成手机号的方式，去测试是否注册过当前应用，如果已注册，就进入忘记密码页面，通过手机号验证码方式找回账号。
忘记密码页面，输入上面的手机号，点击发送验证码后，后端会下发验证码到该手机号上，这个验证码现在只有两个人知道：
手机号主本人后端服务当然是不可能直接打电话给号主本人要验证码的，所以从后端服务下手。
随便输入四位数验证码，点击重置密码，会发送校验验证码的接口，请求内附带上客户端输入的验证码，抓包该请求，通过人为构造验证码的方式，进行撞库，直到成功。
由于验证码是四位数字，所以范围锁定在 0000～9999 内，不断请求，消耗数字就可以了，直到响应内返回成功的状态及 token 字符串。
将 token 字符串、新密码、手机号作为参数传递给更改密码的接口，请求成功后，密码修改成功。
问题分析
1、接口验证码参数为什么没有加密？
这个验证码参数其实是做了加密处理，但是由于在非常老的历史版本上，使用明文传输，为了兼容，所以在低版本的请求上，通过明文传参后端是正常接收并处理的。
2、验证码校验接口，次数没有限制？
这才是根本原因，用户账号是非常重要和基础的业务，后端在更改密码的接口上没有次数限制和风控，应该在试错 N 次后，直接取消本次验证码校验，直接认为失败。
该问题属于安全范畴，日常工作根本不会去注意。这也反映出测试同学在日常工作中，需要通过各种复杂的业务问题，来提高预知风险的能力，丰富项目测试的经验，这才是真正的工作经验。
我认为上述是一个比较好的案例，分享给大家，共同学习。
另外，安利一个好用的接口测试工具 – burp suite。