作者：温景行-549｜8 年安全工程师｜专注安全加固与风险防范，爱打比方 栈：Spring Boot 3.2.4、Spring Security 6.3、Tomcat 9.0.80、Redis 7.2（会话外置）、Nginx 1.25 结论先行：「登录前给没登录的人发个 session」这件事本身没错，错在「登录后不换 session」——攻击者提前塞给你的那把钥匙，登录之后还照样能开门。 会话固定（Session Fixation）不是教科书里的冷门漏洞，它是 CSRF 和账号劫持的「放大器」，而绝大多数团队的 WAF 和日志对它全程静默。
一、现象：转账接口 47 笔异常，WAF 零告警，日志「一切正常」
去年 Q4 给一家做 B 端财务 SaaS 的客户做加固复盘。他们的核心链路是：用户登录后拿到 JSESSIONID，之后调用 POST /api/v1/transfer/execute 发起转账，服务端用 Session 里的 userId 识别身份。
一次例行审计里，风控同事拉出 47 笔可疑转账（合计 [已脱敏] 级别金额），特征诡异：
- 47 笔全部来自 4 个 userId，但源 IP 分散在 11 个不同网段；
- 每一笔转账请求都带了合法有效的 JSESSIONID，签名校验通过、CSRF token 也在（他们用的是同步器）；
- WAF 当天告警数为 0，审计日志里这 47 笔请求看起来和用户自己操作没有区别；
- 事后溯源发现：4 个用户里 3 个承认「我没发起过这笔转账」，而他们的浏览器 Cookie 里，那个 JSESSIONID 的首次出现时间比他们的登录时间早了 3~6 小时。
最后一条是钥匙。
二、根因：攻击者「预开」的门，登录时没人去换锁
打个比方：酒店给每位客人发房卡，本来流程是「前台登记 → 发新卡」。但这套系统做的是「大堂里随便发一张房卡，你先拿着，登记完照样能用」。攻击者要做的只有一件事：在你登记之前，把一张他手里也有副本的房卡塞进你口袋。
机制拆开看，三步：
- 登录前发会话。用户第一次访问任意页面（甚至只是加载一张图片），Tomcat 就
Set-Cookie: JSESSIONID=AAA。此时 Session 里authenticated=false，但 Session 本身已经存在且可被引用。 - 攻击者获知并持有这个 ID。途径很多：恶意链接里直接带
?JSESSIONID=AAA（用户点了就「固定」成功）；同域第三方脚本通过 XSS 或日志侧信道拿到；甚至像文中另一类问题——任何把 JSESSIONID 写进 Referer、日志、URL 重定向的地方都是漏点。 - 受害者登录后，Session 不换 ID。Spring Security 默认不会在
Authentication变化时轮换 Session ID（SessionAuthenticationStrategy默认实现只更新 Session 里的属性）。于是攻击者手里那张「未登录的房卡」，瞬间变成「已登录、且绑定受害者 userId 的房卡」。之后他拿着它调任何接口，服务端眼里都是「本人操作」。
为什么 WAF 静默？因为每一条请求单独看都是合法的：ID 有效、签名有效、来源 IP 是正常用户网段。这和时序侧信道绕过「基于内容的防御」是同一个道理——防御方在检查「内容对不对」，攻击方在污染「身份从哪来」。
而 CSRF 在这里是第二把钥匙：即使受害者自己浏览器里 Cookie 也是 AAA，攻击者诱导他点一个跨站表单（POST /api/v1/transfer/execute），浏览器会自动带上 Cookie——受害者本人也被固定进了攻击者控制的 Session。会话固定把「谁拥有这个 ID」变成了攻击者可操控变量，CSRF 负责「让浏览器替攻击者发请求」，两者组合后，同步器 token 也救不了你（token 同样存在被固定 Session 可触达的页面上）。
三、具体做法：五处加固，全部可复现
1) 登录成功即轮换 Session ID（核心防线）。
Spring Security 里显式换成 ChangeSessionIdAuthenticationStrategy，并在策略里加「旧 Session 内容迁移 + 旧 ID 立即失效」：
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
var strategy = new ChangeSessionIdAuthenticationStrategy();
strategy.setMergeSessionFixation("newSession"); // 迁移属性到新 Session
http.sessionManagement(s ->
s.sessionAuthenticationStrategy(strategy)
.maximumSessions(1)); // 一个账号只允许一个活跃会话，逼出异常
return http.build();
}
同时在网关/应用层加一道兜底：认证状态从 false→true 的跃迁事件（登录、SSO 回调、MFA 通过）都必须触发 session.invalidate() + 重发新 JSESSIONID，任何一条登录路径漏掉都等于白做。
2) Cookie 三件套一个都不能少：
Set-Cookie: JSESSIONID=...; Secure; HttpOnly; SameSite=Strict
SameSite=Strict 直接掐断大部分 CSRF 场景下「跨站请求带 Cookie」的路径（注意：Strict 会打断从外部链接回来不带 Cookie 的场景，B 端跳转多的用 Lax 起步）。
3) 敏感操作二次校验，别只认 Session：
// 转账接口：Session 之外，再加「本次会话内的操作凭据」
@PostMapping("/api/v1/transfer/execute")
public Result execute(@RequestBody TransferReq req,
@SessionAttribute("op_secret") String opSecret) {
if (!MessageDigest.isEqual(
req.getOpToken().getBytes(), opSecret.getBytes())) {
return Result.deny("OP_TOKEN_INVALID"); // 恒定时间比较，别用 equals
}
// ...
}
op_secret 在每次登录轮换 Session 时重新生成，攻击者就算拿到旧 ID 也没有当前凭据——身份（你是谁）和会话（这次连接）解耦校验。
4) 登录前不发「可被固定」的 Cookie： 对未认证请求，Tomcat 配置里把 sessionCookies 的生成推迟到首次需要写 Session 属性时才发生（或网关层对匿名请求剥掉 Set-Cookie: JSESSIONID），让攻击者「没卡可偷」。
5) 审计加一列「Session 首见时间」： 日志里记录 sessionCreatedAt 与 firstSeenAt，firstSeenAt - sessionCreatedAt > 阈值（如 30 分钟）且该 Session 发生过认证跃迁的请求，直接进风控队列——这次 47 笔转账，靠这条规则 100% 能拦。
四、踩过的坑（反直觉处）
SameSite=Lax+maximumSessions(1)会误伤多标签页用户：两个标签页先后登录同一账号会互踢。我们上线第一周收到 12 条工单，最后改成「同账号多会话但敏感操作需 op_token」的折中。- 轮换 Session ID 后，Redis 里的旧 key 不删，等于没换：外置会话时
invalidate()只在本地生效过一次，旧 key 按 TTL（我们原来设 30 分钟）还能活 30 分钟。必须在轮换逻辑里显式redis.del(oldId)，这次 47 笔里有 31 笔就是靠旧 key 余温完成的。 MessageDigest.isEqual两侧长度差异会泄露长度——它只保证逐字节比较的时序恒定，长度不等时仍会提前返回。生产里要先把两边 pad 到等长。
五、结论与可复用清单
会话固定的本质：攻击者不偷你的钥匙，而是提前把钥匙放进你口袋，赌你登录时不换锁。 防线不能建在「ID 是随机的」上，要建在「认证状态变化时 ID 必然变化」上。
- [ ] 所有登录路径（密码 / SSO / MFA）统一走
ChangeSessionIdAuthenticationStrategy并验证「旧 ID 立即失效」 - [ ] Cookie：
Secure + HttpOnly + SameSite（Strict 或 Lax 按业务选） - [ ] 敏感接口 = Session 身份 + 会话内操作凭据双重校验，比较用恒定时间算法
- [ ] 外置会话（Redis）轮换时显式删除旧 key，别信 TTL
- [ ] 审计日志加
sessionCreatedAt / firstSeenAt两列，首见延迟超阈值进风控 - [ ] 把「JSESSIONID 出现在 URL / Referer / 日志」列入代码评审红线
（参考：社区 @温寒山-879 谈过的「决定权绝不能交给请求头本身」，与本文同源——任何身份标识，只要它可以在认证前被外部指定，它就是攻击者的变量，不是你的凭证。）