在逻辑漏洞中，任意用户密码重置最为常见，可能出现在新用户注册页面，也可能是用户登录后重置密码的页面，或者用户忘记密码时的密码找回页面，其中，密码找回功能是重灾区。
首先，在大家了解此漏洞的基础上，需要先了解2种密码重置的方式以便于漏洞理解。
第一种：认证值未起作用。
http://www.freebuf.com/articles/web/164090.html
第二种：用户混淆
没有空看完那两篇文章的童鞋，可以直接看我讲解。有时间的可以跳过讲解直接看文章。
第一种：
就是用户在密码重置的时候，返回一串密文作为认证值，但是由于程序编写错误，这个认证值未起作用，可以使用任意认证值进行密码重置。
第二种：
就是用已知账号1填入身份验证，进入第三步，设置新密码处暂停。然后打开浏览器用账号2进入第二步，这样cookies就被刷新为账号2的，重置的就是账号2的密码了。
此处漏洞，有点特殊，需要两种密码重置思路进行配合一起绕过，达到密码重置的目的，属于密码重置更深入的利用。
以下域名用hacker替代，进行实战演示：
账号1：
http://loan.hacker.com/fpwd1 首先，打开页面。
填入自己注册的账号，然后点击下一步：
然后填入手机接收的验证码，点击下一步：
到第三步后，然后点击下一步进行抓包，记住这个包不能提交出去：
可以看到，系统验证码key key2是加密的。在此处猜测：
key是第一步生成的，作用为确定用户账户。
key2是第二步生成的，是作为像验证码一样的东西作为绑定该账号。
也就是我们要同时知道key和key2的密文才可以重置密码。难度加大。
在此处，我们考虑使用第二种方法，使用用户混淆来尝试下，是否可以重置密码。
账号2:
我们在相同浏览器，再次打开一个页面重置15041452711账号，来到第二步，看到了浏览器有这个东西：
然后将key替换我们刚才账号1第三步抓取的数据包，然后进行提交：
替换完后，提交，显示失败，现实是很骨感的。我们刚才分析过，key是作为用户标识，所以此处必须匹配key2才可以进行密码重置。 但是这个key2无法在页面中获得。于是想到第一种方法，用户的认证值是否可以为空呢？
我们删除key2的参数试试：
然后成功设置15041452711的账号。我们登录看看：
可以看到，密码重置成功。经过我大量测试，发现只有2种密码重置方法同时配合使用才可以使得密码重置成功。在第二步直接获取key，第三步删除key2也是无法重置用户密码的。
有时候，细心点，就能发现别人发现不了的问题。
另外，此漏洞并未修复，主要是分享技术，已打码，请勿尝试。
*本文原创作者：风之传说