任意用户密码重置
(0)

1.验证码不失效

原理:找回密码的时候获取验证码,获取后缺乏时间限制仅仅判断值是否正确,而并没有判断验证码是否过期

测试方法:通过枚举找到真正的验证码输入验证码完成验证

抓数据包然后通过 Burpsuite Intruder 模块 Sniper 即可进行爆破:

验证码不失效,判断的方法仅仅是判断手机验证码有没有误,而那个字符的验证码却不更换,也不报错,所以可以通过枚举。

2.验证码直接返回

原理:获取验证码以后,验证码在客户端生成,并直接返回在返回包以便在接下来的验证码进行比对
[这...有点 6 啊,编写的时候不怕么...]

测试方法:获取验证码 ---> 观察返回包
[现在这种情况很少了]

3.验证码未绑定用户

原理:输入手机号和验证码进行重置密码的时候,仅对验证码是否正确进行了判断,也就是说,并没判断这个是不是这个手机号码发的

测试方法:在提交手机号和验证码的时候,替换手机号为他人手机号进行测试,成功通过验证并重置他人密码
把收到的验证码输入,拦截数据包

然后替换包里的目标手机号,这里就是没有验证手机号码和验证码是否匹配

还有一个案例一样的原理,没有判断用户名是否匹配,点击保存然后抓包可以修改用户名即可修改密码

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

造成原因:用户名/手机号/验证码三者没有统一进行验证,仅判断了三者中的手机号和验证是否匹配正确,如果正确则判断成功并进入下一个流程。

测试方法:输入用户名获取验证码,修改接收验证码的手机号为自己的号码,自己手机成功接收验证码,提交到网站进行验证,验证成功并进入下一流程。
这算是比较常见的漏洞。

5.本地验证的绕过

原理:客户端在本地进行验证码是否正确的判断,而该判断结果也可以在本地修改,最终导致欺骗客户端,误以为我们已经输入了正确的经验

测试方法:重置目标用户,输入错误验证码,修改返回包,把错误改为正确的,即可绕过验证步骤 ,最终重置用户密码,比如说验证为 0 就是正确的,错误返回 1 ,那么只需要把返回包改 1 为 0

6.跳过验证步骤

原理:对修改密码的步骤没有校验,点击获取验证码以后,直接可以抵达修改密码的界面,相当于第二步骤获取验证码验证验证码就是个路人

测试方法:首先使用自己的账号走一次流程,获取每个步骤的页面链接,然后记录页面3 对应的输入新密码的链接,这就可以获取他人验证码然后跳转到改密界面达到重置他人用户密码的目的

7.未校验用户字段的值

原理:在整个重置密码的流程中,只对验证码和手机号做了校验,未对后面设置新密码的用户身份做判断,导致在最后一步通过修改用户身份来重置他人的密码

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

8.修改密码处 id 可替换

原理:修改密码时,没有对原密码进行判断,且根据 id 值来修改用户的密码,类似 SQL 语句:update user set password="123456" where id =1

测试方法:抓包尝试修改 id 即可

9.cookie值的替换

原理:在最后一步要通过的时候,可以看到身份验证仅仅是靠 cookie 值来判断是否是当前用户,那就可以回到第一阶段,获取验证码,从而获取到 cookie 值,然后修改

测试方法:重置自己用户密码到达最后阶段,抓到数据包,并在第一阶段重新获取用户 cookie,替换 cookie 到我们抓取的数据包中,发包测试。

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

原理:在执行修改信息的 sql 语句时,用户的密码也被当作字段执行了,而且是根据隐藏参数loginid 来执行的,这样就导致可以修改隐藏参数 loginid 的值,达到修改他人密码的目的。

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


测试总结:完完整整先走一遍流程,然后把每一个包都抓下来,对每一个包进行测试,特别是修改密码,忘记密码,修改个人信息,最好是把流程步骤画下来。

本文为作者HD_More发布,未经允许禁止转载!
上一篇 下一篇
评论
暂无评论 >_<
加入评论