以前安全测试最爱挖的就是任意用户密码重置，今天看了carry_your师傅在ichunqiu上的视频文字总结一下任意用户密码重置的10种姿势：
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。
carry_your师傅的课程链接：
https://www.ichunqiu.com/course/59045
