Session覆盖测试(要验证码提交到后续页面操作的 绕过去的场景)

测试原理和方法

找回密码逻辑漏洞测试中也会遇到参数不可控的情况，比如要修改的用户名或者绑定 的手机号无法在提交参数时修改，服务端通过读取当前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的方式篡改了要重置密

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