【转】

1.伪造请求（未注册的情况下）

在请求密码修改的过程中，修改账号的手机或邮箱等联系方式，在接受到验证码后进行密码修改。12

 

 修改了接受密码手机，并且通过对账户类型的修改绕过边界。

2.使用正常账户请求修改获取token

 1. 爆破（绕过次数验证）12

 

原因：验证码过于简单，并且没有对请求修改次数做出限制。  原因：虽然设置了请求阀值，但被猜解除了验证方式，病找到了绕过方式，验证码为4-5位的数字容易爆破

 2. 猜解12

 

原因：使用了特定值的加密作为token，被猜解到使用了时间戳的MD5值。在实际过程中我们也可以尝试用户名，手机，邮箱，等等的不同加密方式。

 3. 在客户端寻找token信息12

 

原因：没有严格控制token，在返回的url中发现token信息  原因：找回密码问题的答案在页面源码中可以看到……

3.通过验证提交修改请求时存在的漏洞

  在请求过程中修改用户uid12

 

 原因：没有管理好token和用户间一对一的关系，导致在最后提交请求的过程中修改了uid导致任意用户密码重置。

4.边界绕过特殊案例

 

过程：注册过程的绑定手机页面用过参数修改，将任意账号绑定至可控手机，在通过密码找回流程找回

以上资料均来自乌云知识库~

将回答密码找回问题的参数删除，服务端竟然通过了

重置密码时填入其他人的ID

重置密码时填入其他人的手机号

重置密码时填入其他人的邮箱

发送重置密码验证码时填入自己的手机号

发送重置密码链接时填入自己控制的邮箱

进入密码重置流程，获取cookie之后，将需要重置的目标账号等信息填写为其他人的

进入密码重置流程，获取cookie之后，可直接访问密码修改链接

进入密码重置流程，获取验证码之后，通过走别人的密码重置流程，用来重置别人的密码

重置密码过程中，修改步骤（stop）参数，绕过校验，直接进入系统

前端做校验，直接拦包修改服务端返回码即可绕过

用别人的账号重置密码，修改服务端返回的手机号为自己的手机号，使得自己接收到验证码

重置账号输入点存在SQL注入

用自己的账号进行重置密码，在收到正确cookie后，将标识用户账号的参数改写为其它人的账号

【覆盖】注册一个和现有用户名一样的用户，直接把密码改了，信息却还是老用户的

同一浏览器内，用户A走重置密码流程到接收到重置密码链接，用户B走重置密码流程到接收到重置密码链接，用户A点击重置密码链接，进入到对用户B的密码重置流程

验证码为4至6位数字，爆破

验证码直接在链接里出现

重置密码用的加密串不用验证就能获得，在输入验证码前就可以得到

找回密码的答案竟然在HTML里返回了

手机验证码竟然直接返回给了浏览器

重置密码认证信息用时间戳md5运算后做token，用两个账号走重置密码流程做对比可以发现该漏洞

【绑定手机】通过修改链接中的uid将其他人的密码找回手机绑定成自己的手机

越权修改其他人的密码找回手机