导语:上一讲 day16 把 Web 缓存层那条线讲完,今天切到应用层的会话(Session)变量滥用。Session Puzzling 又叫 Session Variable Overloading,原理很朴素——应用把同一个 session 变量在多个地方读写,攻击者能控制访问顺序,先用未鉴权的 A 页面把变量塞进去,再去访问要鉴权的 B 页面绕过登录检查。OWASP WSTG-SESS-08 把这类攻击列在认证之后、CSRF 之前的章节,威胁等级不容小看。
一、什么是 Session Puzzling
OWASP Web Security Testing Guide 的 WSTG-SESS-08 给的定义——”Session Variable Overloading (also known as Session Puzzling) is an application level vulnerability which can enable an attacker to perform a variety of malicious actions”。关键句:“when an application uses the same session variable for more than one purpose”——同一个 session 变量被复用在多个用途上。
变量复用本身不是 bug,问题出在”逻辑流被打乱”。应用开发者通常假设用户按预设路径访问页面——”必须先访问 X 设置 session 变量,再访问 Y 检查变量”。攻击者偏不按顺序——先访问 X 把变量塞进 session,再访问 Y,Y 的检查就通过了。

一句话总结:session 变量在多入口点之间出现逻辑混乱——开发者只考虑了正常访问路径,没考虑攻击者能控制访问顺序。
二、OWASP 列出的五大危害
WSTG 列的危害面比”绕过登录”宽得多:
- 绕过认证——未鉴权页面把 session 变量塞好,再用它通过鉴权页面的检查。
- 提权——普通用户态的入口塞高权限标记,借 session 变量在另一个上下文被当管理员。
- 跳过多阶段流程——支付流程(绑手机 → 输验证码 → 输支付密码 → 扣款)原本要四步,攻击者用第一步就能跳到最后一步。
- 操纵服务端值——服务端某些值本来要经计算才确定,攻击者用 session 变量直接覆盖,最终值变成攻击者控制的输入。
- 打开原本不可达的攻击面——CSRF、XSS、SSRF 这些攻击因为鉴权门槛被挡住的位置,绕过鉴权后全打开。
三、最经典攻击场景:忘记密码页
原文给出的场景非常典型,也是大多数红队打点时第一个会测的地方:
1. 攻击者访问 /forget_pass
2. 提交受害者用户名(或邮箱),触发密码重置请求
3. 应用把"用户名"或"用户 ID"写进 session 变量(cookie 跟着变化)
4. 攻击者带着这个 cookie 去访问 /my_profile
5. /my_profile 的鉴权逻辑只检查"session 里有没有 username/uid",不检查"是不是经过完整登录流程"
6. 直接拿到受害者的个人资料页
为什么开发者会写出这种代码?最常见的原因有三个:
- 想偷懒——鉴权逻辑只写了一个”有 session 变量就放行”的判断,没区分变量是被”正确登录流程”还是”忘记密码流程”塞进去的。
- 历史包袱——以前只有登录页往 session 写变量,加了忘记密码页后没改鉴权判断逻辑。
- 多系统 SSO 复用——单点登录系统把多个子系统的鉴权变量都映射到同一个 session 字段。
PoC 骨架:
import requests
s = requests.Session()
s.post("http://target/forget_pass", data={"username": "victim"})
r = s.get("http://target/my_profile")
print("命中" if "victim" in r.text else "未命中")
四、入口点 vs 出口点:枚举法
WSTG 给出的测试方法论是”识别所有 session 变量 + 打乱逻辑流”。落到红队打点流程上,分四步:
Step 1:枚举入口点——未鉴权但会写 session 的页面:/forget_pass、/signup、/contact、/newsletter_subscribe、/oauth/callback,以及任何 GET 请求会 Set-Cookie 的页面。
Step 2:枚举出口点——检查 session 变量判断身份的页面:/my_profile、/admin、/api/me、/orders、/settings。
Step 3:交叉尝试——每个入口点 × 每个出口点组合,挨个打。
Step 4:观察差异——响应内容、状态码、Set-Cookie 头变化——任何一处能区分”登录用户”和”未登录用户”都是潜在攻击面。
五、Boomerang Effect:Shay Chen 的经典研究
Session Puzzling 不是新概念。Shay Chen 在 2013 年 DeepSec 大会发表”The Boomerang Effect – Using Session Puzzling To Attack Apps From The Backend”,命名 Session Puzzles,并发布 Puzzlemall 漏洞演示应用。
核心观点:”间接应用层攻击向量”——很多应用层攻击看似 XSS、CSRF、SQL 注入,根因是 session 变量被滥用,把不同页面的逻辑”穿”到一起。Boomerang(回旋镖)这个名字很形象——攻击从一个页面”飞出去”,绕一圈回到另一个页面”打中”。
Puzzlemall 给了 7 个 demo 用例,覆盖典型入口点模式:忘记密码、注册流程、匿名反馈、邮件订阅等。这些用例今天依然可以在 KBID-250 的 OWASP SKF 实验环境复现。
六、检测与自动化
手工检测:
- 浏览未鉴权页面,Burp 抓所有 Set-Cookie 的请求
- 单独把 cookie 复制到无痕窗口,去访问鉴权页,看是否进入登录态
Burp 插件:
- Autorize——自动检测低权限 Token 访问高权限 URL 的越权,但主要针对鉴权 token 复用
- Param Miner——参数挖掘,能找出隐藏的 session 字段
- Logger++——抓所有 Set-Cookie 头,方便做交叉对比
灰盒 / 源码审计:
最有效的方式是直接看代码,搜索”session.setAttribute”、”$_SESSION[“、”HttpSession” 这类 API 出现的位置,找出在多个页面复用的变量名——一个变量在两处以上被 set 就要查。
Fuzz 思路:用 Burp Intruder 把所有可能的”入口 URL × 出口 URL”组合打一遍,观察响应码 + body 长度的差异(Intruder 的 Grep – Extract 配 length 列)。
七、修复方案
按层级给:
会话变量设计层——一个变量只承担一个用途,禁止跨页面复用;关键鉴权变量加流程阶段标记,比如 session 里除了 username 还要有 login_stage=completed,多阶段流程每个阶段都打标记,最后阶段才设为 completed。
代码层:
// 反例:只检查变量是否存在
if (session.getAttribute("username") != null) { showProfile(); }
// 正例:检查变量值 + 流程标记
if ("completed".equals(session.getAttribute("login_stage"))
&& session.getAttribute("username") != null) { showProfile(); }
架构层——鉴权中间件(Filter、Middleware)做统一检查,不要每个出口页面单独写;JWT 应用在签名里带上 audience/scope 字段区分 login 颁发 vs reset 颁发。
测试层——自动化测试覆盖”打乱访问顺序”,单元测试里 mock 出”A 页 → 直接 B 页”路径,断言 B 页应该 redirect 到登录页。
八、思考题
- 某应用的 session 里同时存
username和login_method,鉴权检查只验证username != null,不看login_method值——攻击者能否通过”邮箱订阅”页(会写 username)跳过登录? - 分布式部署下,应用 A(忘记密码服务)和应用 B(个人中心)共享同一个 Redis session 集群,跨服务复用同一个变量名有什么额外风险?
- Session Puzzling 和 Insecure Direct Object Reference(IDOR,不安全的直接对象引用)都能”绕过检查读取别人的数据”,两者在代码层的根本差异是什么?
下一篇 day18 会拆解 Mass Assignment——框架自动绑定请求参数到对象时的赋值漏洞。
九、素材出处
- Learn365 Day 17 原文:
https://github.com/harsh-bothra/learn365/blob/main/days/day17.md - OWASP WSTG-SESS-08:
https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/08-Testing_for_Session_Puzzling - Shay Chen 2013 DeepSec:The Boomerang Effect:
https://deepsec.net/docs/Slides/2013/DeepSec_2013_Shay_Chen_-_The_Boomerang_Effect_-_Using_Session_Puzzling_To_Attack_Apps_From_The_Backend.pdf - OWASP SKF KBID-250 实验:
https://owasp-skf.gitbook.io/asvs-write-ups/kbid-250-session-puzzling - Puzzlemall 漏洞演示应用:
https://code.google.com/archive/p/puzzlemall














暂无评论内容