任意用户密码重置10钟常见姿势

1、验证码不失效（验证码爆破）

产生原因：会话缺少对验证码检验功能失郊。

利用方法：通过枚举进行验证码爆破，取值范围:000000-999999，Burp可以实现这个功能。

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

产生原因：输入手机号后点击获取验证码，验证码在前端生成，并直接返回在Response包中。

测试方法：输入任意手机号，点击获取验证码，并观察返回包，在返回包 中直接得到目标手机号获取验证码。

3、验证码没有绑定用户

产生原因：输入手机号和验证码进行重置密码的时候，仅对验证码进行了判断，未对该验证码是否与手机号匹配做校验。

测试方法：在提交手机号和验证码的时候，替换手机号为他人手机号进行 测试，成功通过验证并重置他人密码。

4、修改接收验证码的手机或邮箱

产生原因：用户名、手机号、验证码三者没有统一进行验证，仅判断了三者中其中的手机号和验证码是否匹配正确，如果正确则判断成功并进入下一步。

测试方法：输入用户名获取验证码，修改接收验证的手机号为自己的号 码，将接收到的验证码提交进行验证。

5、本地验证绕过

产生原因：由于系统在前端进行校验，导致可在数据包更改参数值，然后发送请求，服务器误以为已经输入了正确的验证码。

测试方法：输入错误的验证码，修改返回包中的参数值，既可绕过验证。

6、跳过验证步骤

产生原因：对修改密码的步骤，没有做校验，导致可以直接输入最终修改 密码的Url，直接跳转到该页面，然后输入新密码达到重置密码的目的。

测试方法：首先使用自己的帐号先测试，把重置密码步骤Url做记录，然后重置他人用户时，直接输入修改新密码的Url。

7、未校验用户字段的值

产生原因：在整个重置密码的流程中，只对验证码和手机号做了校验，未对后面新密码设置的用户身份做校验，导到在最后一步通过修改用户身份来重置他人的密码。

测试方法：使用自己的手机号走流程，在最后一个设置新密码的流程时候，修改数据包里的用户信息。

8、修改密码处ID可替换

产生原因：修改密码的时候，没有对原密码进行判断，且根据ID的值来修改用户的密码，类似SQL语句:update user set password = "123qwe" where id ='1'修改数据包里的ID值，既可修改他人的密码。

测试方法：修改自己的用户密码，抓取数据包，替换数据包中的用户对应的ID值，即可修改他人的密码。

9、cookie值的替换

产生原因：重置密码到最后一步的时候，仅判断用户的Cookie是否存在，并没有判断该Cookie有没有通过之前的重置密码过程的验证，导致可替换Cookie重置他人的用户密码。

测试方法：重置自己用户密码到达最后阶段，抓到数据包，并在第一阶段重新获取目标用户Cookie，替换Cookie到抓取的数据包中发包测试。

10、修改信息时替换字段值

产生原因：在执行修改信息的时候，用户的密码也当作字段执行了，而且是根据隐藏参数loginid来执行的，这样就导致修改隐藏参数loginid的值，就可以修改他人的用户密码。

测试方法：修改个人资料的时候，抓取数据包，然后来修改数据包的参数和对应的值，参数名一般可以在其它地方找到，替换隐藏参数即可修改他人的密码信息等。

【声明】

此篇文章纯属造轮子娱乐，如果不喜欢请点击左上角。若其他人带有攻击性测试，造成后果一切自负。

Like knows like

惺惺相惜