密码重置姿势总结​

前言:写这篇文章主要是想总结一下这块的问题,之前总是测一两点就忘记测另外的点了。逻辑这块其实骚姿势一直都很多。案例有借助网上表哥的也有自己挖掘到的。

验证码回显客户端
验证码爆破
验证码未效验
万能密码

重置密码时，凭证为发送到手机上的验证码，但是通过拦截发送发送验证码请求对应的response包时，发现验证码在response包中，这种情况通常是开发为了方便判断用户输入的验证码是否和响应中的一致。接受短信的时候打开f12查看一下返回包就好。虽然现在比较少了。
修复建议:避免验证码返回到响应包中 放在服务端验证

验证码效验的时候，没有做次数时间限制(四位数十分钟是可以爆破出来的),可以使用枚举来猜测正确的验证码。使用burp进行爆破就好。如果状态码和字节长度一样可以正则匹配关键字。
修复建议:采取错误次数限制,输入错误验证码五次后锁定用户半小时

服务器只判断验证码是否正确,没有判断是否与用户匹配。利用我的手机号接受验证码可以用过验证。
修复建议:绑定用户与验证码是否一致

万能密码的话主要是开发在业务未上线的时候为了方便测试用的,上线后忘记删除了,例如8888 0000 1234等等 都可以去尝试

有些开发在返回包里设置一个参数，这个参数用于传递给前台以决定我们是否可以进入下一步。但我们可以通过拦截返回包修改里面的值欺骗前端绕过验证码,如false改成true error 1改为0，可以使用自己的账号走一遍流程记录下来正确的状态码然后替换做尝试。修复建议:不要在前端利用服务端返回的值判断是否可以修改密码 要把整个效验环节交给服务端

这种一般发生在多个步骤重置的过程中，未对步骤1，2进行校验，通过修改url直接绕过短信验证码的校验步骤(用自己的账号走一遍记录url,可能是post包 修改Post请求也可以 step1改为3)，直接进入重置页面进行重置。修复建议:判断用户是否通过步骤1,2通过才能进入修改密码界面。

重置密码时，凭证会发送到手机上，通过替换手机号，可以使用自己的手机号接受验证码。在发送短信的时候修改为自己的手机号接受验证码即可通过

修改密码时,没有对当前用户进行判断且根据id的值来修改用户密码,修改自己的密码,修改数据包中用户对应的ID值，便可修改他人密码。修复建议:判断用户id值是否一致

在整个重置面的过程中只对验证码和手机号做了效验,未对后面设置新密码的用户的身份进行判断,攻击者可修改用户身份来重置他人密码。修改id值也可以。修复建议:判断手机号验证码用户是否一致

session覆盖（也可以说是Cookie混淆），意思就是说不管使用那个用户进行重置密码操作，session都是固定了，只是绑定的用户不同（有时候只是用户的登陆状态不同，所以sessionid固定也会导致会话固定漏洞）。简单的说：就是第二次发送给服务端的session覆盖了第一次发送给服务端的session，从而通过了验证。利用方法：使用攻击者的账号走重置密码的流程，到最后一步也就是提交新密码时不要点击提交或者使用burp拦截请求包，在同一浏览器中打开重置密码的页面，使用受攻击者的账号走流程，到需要输入手机验证码的时候，session就已经和收攻击者的账号绑定在一起了。再将之前我们拦截的提交新密码的请求放行，这时后台程序修改的将是受攻击者账号的密码。