2026-10-16 03:42:17 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

Session Puzzling 攻击：会话变量滥用与认证绕过

原创

Red Hunter
Red Hunter

黑白之道

2026年10月8日 09:00
韩国

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

导语：上一讲 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