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

原学习视频链接: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与用户名或其他用户标识的对应值,但视频中因为是上帝视角,没有提及,所以在实际情况中,要结合其他方式利用。

原文地址:https://www.cnblogs.com/foe0/p/11357030.html