缺少对时间限制,导致可枚举验证码
【比较常见的是4位验证码爆破】
验证码直接出现在返回包里
【这个例子很好理解,抓包查看返回即可发现】
只判断验证码是否正确,未判断该验证码是否属于该用户
【该例子较为常见,就不做过多解释了】
跟第三个有点类似,只判断了接收端和验证码是否一致,未判断接收端是否和用户匹配,因此修改接收端可达到重置目的
【用户名,手机号,验证码三者未统一验证】
这个很好理解,就是密码重置的逻辑代码功能写在前端,此时可以修改返回包可绕过,还见过一种可直接禁用JS就可找回密码的,有点奇葩
这种方法就是逻辑流程出问题了
比如重置密码分4个步骤
1-2-3-4-成功,加入利用新账号走一遍整个密码重置流程
然后记录下每个步骤的url或者数据包
接着从1试着直接跳到4【输入4的url】看能不能跳过
【仔细想想是不是很多通过邮箱密码找回的很多类似这种模式的,会给邮箱发送一个特定的重置连接,如果可以破解这个链接,意味着很大可能可以绕过密码重置】
这个和0x2和0x3又有点相似了,还是因为没有完整匹配的原因,在最后一步的时候,修改用户名则可成功重置
【这个可批量重置密码】
【密码重置的功能,一定要每一步都进行匹配】
【用户id---用户手机号---手机验证码---用户名---用户邮箱】
此项也是因为匹配的问题出错,如果未过任何加密可能危害极大,可遍历id修改密码
核心SQL语句
update user set pass=“123456” where id =“1”
通过修改自己密码,然后替换数据包中的对应id值,即可达到修改他人的密码
在重置密码的时候,可能没有代入任何可直观的判断属于哪个用户的字段,但是这时候可能该判断就在cookie里里面
【那么这个cookie值可能可以在重置的时候第一步,或者第二步获取到】
例如在修改个人资料的时候,添加隐藏参数uid或者userid,loginid,这个参数名一般很多地方抓包都可以看到,替换隐藏参数就可以修改他人的密码等信息
之前还见过一种密码重置,就是密码重置的时候,只判断验证码是否正确,但是没有对验证码为空做判断,此时可试试删掉验证码,看能否成功
有时候忘记密码的连接是根据一个token来字段来重置的,有时候这个token会在重置成功前就给出,这时候根据tokne泄露的就可以任意重置了
有些密码重置是通过设置问题答案来重置,通过找回密码功能,在页面的源代码里,不但有密码提示问题,Hide表单里可能泄露问题答案,可获得任意用户修改密码问题答案,从而轻松修改任意用户邮箱密码
这种一般在邮箱密码找回,例如
重设密码地址:http://XXX/findpwd/setpwdfromemail?vc=token值&u=用户名
这边vc是一段修改密码的token,如果token是一段时间戳,此时通过这段时间内爆破,就可以重置密码
一般在邮箱接收密码重置的连接时比较多,随机token只相差4,网络有点卡,如果是网络好,应该只相差1-2,token轻易被猜出来。
其实核心思路就是要细心,密码重置的功能每一步都走一遍,然后记得每一个步骤的包,每个参数都有什么作用,这样你也能挖到意向不到的高危逻辑漏洞