实现一个业务功能，也有着很多不同的实现方式，当业务逻辑考虑不严谨的时候，同一个业务功能模块存在着很多漏洞场景，如密码重置漏洞、商城支付漏洞等。
本文分享一个有意思的案例，通过漏洞组合实现任意密码重置，同时，也是验证码验证一次有效的利用场景。
1、在这个密码重置模块里面，只需输入手机号和手机验证码即可进入修改密码界面，看到这个界面，很多人会尝试暴力破解，但会发现验证码仅能使用一次，爆破成功，但输入的时候已经失效了，怎么办？
2、 我们填写用户的手机号码，获取验证码，随意输入几个验证码，抓包：
我们注意到返回的是失败，如果返回成功，是什么样子呢？通过测试，如果验证码输入正确，返回{"data":"success"}。
3、修改返回包为{"data":"success"}，即可绕过验证码验证，进入修改密码界面。
4、在这里，输入两次新密码，提示密码修改失败。查看HTTP交互过程，Token值不变。猜想：如何把Token变成有效的，这样才能修改成功。
{"Token":"eyJhbGciOiJIUzI1NiJ9.eyJpczMiOiJmYW5ydWFuIiwiaWF0IjoxNTYyOTI0MzUxLCJzdWIiOiIxaDA0MDI5OSIsIgp0aSI6Imp3dCJ9.Mo0KuEZwOuT6pPsJCydgKD-qVjIieaVAWDX7tchk4NY","newPassword":" IGFiY2RlMTIz"}5、这里，我们利用系统的另一个缺陷，因对手机验证次数没有限制，遍历000000-999999区间，暴力破解手机验证码，成功后返回success
6、此时，输入用户新密码，保存后修改成功。
简单来说，这个漏洞场景是这样：
A、前端验证绕过可以直接进入密码修改界面，但Token无效，无法成功修改密码。
B、手机验证码可以暴力猜解，但验证码一次失效，爆破出来再输入验证码无效。
这个时候，通过A+B的漏洞组合，利用前端验证绕过进入修改密码界面，暴破验证码使Token生效，就可以实现任意密码重置漏洞 。
漏洞往往就隐藏在一些细节里面，在渗透测试中，去分析请求中的每个参数，并注意检查页面返回的源代码。比如，当参数拼接到SQL中执行，就存在SQL注入，当参数直接输出到前端，就存在XSS跨站脚本。
似乎很难再找到人去分享，发现一种新的漏洞利用场景的喜悦。
