任意用户密码重置的十种姿势=====>学习笔记！

原学习视频链接：https://www.butian.net/School/content?id=214%E2%80%98

1.验证码不失效

　　原因：获取的验证码缺少时间限制，仅判断验证码是否不正确而未判断验证码是否过期

　　测试方式：可以爆破枚举找到验证码完成验证

2.验证码直接返回在数据包中

　　原因：输入了手机号后点击获取验证码，验证码在客户端生成，并直接返回在response中

　　测试方法：输入目标手机号，观察返回包中的内容。这种操作一般会在开发测试阶段产生。

3.验证码未绑定用户

　　原因：输入手机号和验证码重置密码时，仅判断验证码是否正确，没有对验证码与手机号匹配做验证

　　测试：先使用自己的手机号获取一个正确的验证码，在下一步中修改密码前抓包修改手机号为目标手机号

　　这里有一个扩展，用户名（用户特征的信息）与验证码没有绑定，替换原理都是一样的，比如替换用户名，替换加密后的用户名，毕竟这里只是一个理论知识，有实际操作支撑时再进行拓展。

4.修改接受的手机或邮箱

　　原因：用户名，手机号，验证码三者没有绑定验证，仅判断了手机号和验证码的匹配正确，这个漏洞我想，肯定是开发。

想偷一下下懒。

　　测试：重置时修改接收验证码的手机号

5.本地验证的绕过

　　原因：这个本地验证听起来很高大上啊，实际上就是一个在本地修改一个验证结果。比如说验证成功返回0，失败返回1，如果在本地可以抓包修改这个值，那么就判定这个漏洞是存在的。

　　　　 　客户端在本地进行验证码是否正确的判断，且该判断结构也可以本地修改，最终欺骗客户端。

　　测试：重置目标用户，输入错误的验证码，修改返回包中的验证结果flag值。

6.跳过验证步骤

　　原因：修改密码的过程中，如果存在多个页面，比如说，输入用户名（url1）点击下一步======>输入接收验证码的手机号或邮箱（url2）======>修改密码的页面（url3），正常操作是验证成功后才会由url2-->url3，所以可以尝试跳过这一验证过程，直接url1----->url3，这个实现前提是你已经正确的按照逻辑实现了并记录下操作的url。

　　测试：先测试一边正常流程并记录url，再对于目标用户重置。

　　

7.未校验用户字段的值

　　原因：在重置流程中，只对手机号和验证码做了校验，没有对后面设置新密码的用户身份做判断，导致最后一步修改用户身份来重置别人呢的密码

　　测试：在通过验证后，修改设置密码流程时，抓包修改数据包里的用户信息。

8.修改密码处id可替换

　　原因：修改密码时，没有对原密码进行判断，且根据ID的值来修改对应用户的密码，如:update user set password = "qwe1234" where id = '1'，可能在验证时会发送多个数据进行验证，但修改操作，即update操作不受其他判断结果影响，所以修改id可以直接起作用。

9.cookie值的替换

　　原因：重置密码时仅判断cookie是否存在，没有判断该cookie是否通过之前的验证过程，导致替换cookie可重置密码。

　　测试：抓取数据包中的cookie值，替换重置密码数据包中的cookie值，达到目的。

10.修改信息时替换字段值，特指隐藏参数loginid

　　原因：在执行修改信息的sql语句时，用户的密码也当作字段执行了，且是根据隐藏参数loginid，修改该参数，就可以修改他人的用户密码。

　　测试：修改个人资料时，抓取数据包，修改数据包的参数和队友的值，替换隐藏参数，成功后被替换的账户密码与自己的密码一致。隐藏参数可以在页面的源代码中找到。

　　在实际利用中，需要知道loginid与用户名或其他用户标识的对应值，但视频中因为是上帝视角，没有提及，所以在实际情况中，要结合其他方式利用。