Question

12.5.1 测试原理和方法

找回密码逻辑漏洞测试中也会遇到参数不可控的情况，比如要修改的用户名或者绑定

的手机号无法在提交参数时修改，服务端通过读取当前 session 会话来判断要修改密码的账

号，这种情况下能否对 Session 中的内容做修改以达到任意密码重置的目的呢？

在某网站中的找回密码功能中，业务逻辑是：由用户使用手机进行注册，然后服务端

向手机发送验证码短信，用户输入验证码提交后，进入密码重置页面。

对网站中 Session 覆盖的测试如下：

（1）需要准备自己的账号接收凭证（短信验证码）；

（2）获得凭证校验成功后进入密码重置页面；

（3）在浏览器新标签重新打开找回密码页面，输入目标手机号；

（4）此时当前 Session 账户已经被覆盖，重新回到第二步中打开的重置密码页面即

可重置目标手机号。

12.5.2 测试流程

步骤一：在找回密码页面中输入 A 手机号（尾号 3274），然后单击“下一步”按钮，

如图 12-23 所示。

图 12-23 找回密码第一步

步骤二：单击“立即验证”按钮，接收短信验证码。输入验证码通过验证后，就可以进

入密码重置页面了，如图 12-24、图 12-25 所示。

图 12-24 找回密码第二步验证手机号

图 12-25 进入重置密码页面

步骤三：这里我们密码重置的目标账号是 B 手机号（尾号为 5743），接下来打开一个

新的标签并进入找回密码第一步的页面，输入 B 手机号后单击“下一步”按钮，如图 12-26 所

示。

图 12-26 新标签重新进入找回密码覆盖 session

步骤四：此时成功进入第二步，向 B 手机号（尾号为 5743）发送验证码。B 手机收到

的短信验证码我们无法得知，但是不要担心，在这一步服务端已经将当前 Session 会话设

置为 B 手机号（尾号为 5743）的用户，这个时候再刷新 A 手机号（尾号 3274）密码重置页

面。

步骤五：通过观察页面上显示的手机号，可以看出已经由 A 手机号（尾号 3274）改为

了 B 手机号（尾号为 5743），这说明 Session 成功覆盖了。这意味着重置密码将修改的是 B

手机号（尾号为 5743）的密码，如图 12-27 所示，这样就又诞生了一个任意密码重置漏

洞。

图 12-27 重新进入找回密码页面

12.5.3 修复建议

Session 覆盖类似于账号参数的修改，只是以控制当前 Session 的方式篡改了要重置密

码的账号，在重置密码请求中一定要对修改的账号和凭证是否一致做进一步的校验。