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