作者：KILL@零度安全攻防实验室核心成员
本文字数：971
阅读时长：6~9min
声明：请勿用作违法用途，否则后果自负
简介
简单记录一下平时漏洞挖掘的时候对于密码重置漏洞的十种方法，有补充的朋友可以回复公众号补充哈。
第一种
密码找回的时候验证码返回在返回包里面，直接截取返回包验证码即可。
第二种
通过返回包状态码判断，比如遇到一个案例，重置成功的返回包为0000，错误的为9999，然后在任意密码重置的时候判断返回包改为0000可重置成功，这种情况视开发而定，每个站的返回包状态码不一样。
第三种
对于用户修改密码没有鉴权，例如密码重置有三步，正常流程测到第二步，在第三步的时候修改username可以修改指定username用户的密码（这种方法不一定是死的，存在可拓展性，比如在A接口泄露的所有用户的id或者用户名，而在用户密码找回的步骤，没有鉴权，就算没有username、userid用户的唯一标识，也可以在这个接口进行参数拼接导致任意密码重置）
第四种
一些服务器的验证问题，把验证码删除，可以使服务器判断为正确的操作。
第五种
用户唯一凭据泄露，不管是否重置成功，返回包都带有用户唯一凭据，可以通过这个返回包的用户凭据添加到请求包里面，完成密码重置。
第六种
验证码未设置过期，可以进行爆破。
第七种
验证码未绑定用户，只对验证码作了判断，但是没有判断验证码的用户，这个时候就可以替换用户进行密码重置。
第八种
修改接受验证码的手机，邮箱，用户名，手机，邮箱，没有作统一的验证，只判断了手机号和验证码是否对应，如果判断成功就进入密码重置。测试方法：修改密码的时候，输入用户名获取验证码，把手机号替换成自己的手机号，如果成功接收，表明网站可能存在密码重置。
第九种
跳过验证步骤，对用户修改密码的步骤没有做限制，可以直接跳过验证，到达修改密码的页面，达到修改密码的目的。方法，先按正常密码重置流程走一次，记录好重置密码页面的url，然后在重置密码的时候，直接访问重置页面的url，若能成功访问。则存在密码重置。
第十种
cookie替换重置，重置密码的时候仅判断cookie是否存在，未判断cookie之前是否通过重置过程验证，导致可替换cookie重置其他用户密码(利用前提：可获取到用户coookie)。方法：重置密码到最后步骤替换其他用户cookie。
