参考文章
本片文章仅供学习使用，切勿触犯法律！
概述
总结
重置密码本身没有问题i，但是在重置密码中的验证机制不够完善。其产生的原因多种多样，最主要的原因是网站有逻辑上的漏洞，即没有做到用户、账号、验证码三者统一进行验证。
一般重置密码流程：
总结为3步：
导致用户账号丢失、信息丢失、财产损失等，对企业来讲，任意账号重置的漏洞将会丢失大量数据，失去用户信任，严重妨碍企业业务，带来巨大的财产损失。
该漏洞存在于用户重置密码一般流程的各个环节。
1. 验证码可爆破
在重置密码的过程中，需要填写验证码以证明操作者是用户本人。无论是验证码是短信验证还是邮件验证码（本质是一样的），存在以下条件的，可以尝试爆破。
2. 短信验证码显示在获取验证码请求的回显中
攻击者知道被攻击用户的手机号码，获取短信验证码，抓包就可以在回显中看到用户收到的重置用的短信验证码。
3. 注册手机号及短信验证码未进行匹配性验证
攻击者用自己手机号码收到的重置用短信验证码可以重置其它用户的密码。
4. 用户名、手机号码、短信验证码三者没有进行匹配性验证
只验证码了手机号码、短信验证码是否匹配，最终重置密码是根据用户名来重置的。攻击者重置用户a的密码，获取短信验证码的时候将手机号码修改成自己账号对应的，获取到对应的正确短信验证码，然后输入短信验证码，由于只验证了手机号码以及短息验证码是否匹配，从而可以成功绕过短信验证码限制来重置用户a的密码。
5. 验证码的验证在本地客户端进行验证
通过修改请求回显来绕过，常见重置姿势之一，也可以用于绕过一些其它的前端验证，比如存储xss，参数的合法性验证如果通过前端来完成，也可以用这种方法。
6. 重置步骤未进行校验
这种一般发生在多个步骤重置的过程中，未对步骤1，2进行校验，通过修改url直接绕过短信验证码的校验步骤，直接进入重置页面进行重置。
7. 重置请求未验证身份
跟方法4差不多，最终重置请求没有验证用户身份信息。攻击者用自己的手机号码短信验证码走重置流程，最后一步重置请求抓包修改身份信息为其它用户的，从而进行其它用户密码的重置。
8. 登陆成功修改密码功能平行越权
用户登陆成功之后可修改自己的密码，修改请求只需要输入新密码，请求中未验证当前用户的cookie、session、id等身份信息，可以通过修改id等来重置其它用户的密码。
9. 未校验身份信息的唯一标识cookie信息
重置请求参数中没有用户名、手机号码、id等身份标识，唯一的身份标识是在cookie中。攻击者用自己的账号进行重置，最后重置请求中替换掉请求中的cookie进行其它用户密码的重置。
10. MVC数据对象自动绑定漏洞
邮箱重置密码或者手机号码重置密码的时候，请求中没有明显的身份标识，可以尝试增加参数值来测试是否存在MVC数据对应自动绑定漏洞。比如增加email参数及对应的自用邮箱作为参数值，看看是否能收到密码重置链接。有关这个漏洞可以看看carry_your师傅视频中的案例，以及CF_HB发过的案例，也可以看看CplusHua有关模糊测试的ppt。
略
根据以上的挖掘方法，不难得出相应的防范方法
原文：https://www.cnblogs.com/gorillalee/p/14364880.html