课程笔记：Session固定与Session保持攻击

课程名称：计算机网络应用 核心摘要：本讲围绕会话（Session）安全展开，重点讲解会话劫持的两种特殊形式——Session固定攻击与Session保持攻击。前者通过诱骗受害者使用攻击者指定的 Session ID 完成劫持，后者则在会话劫持基础上通过持续刷新维持 Session 长期有效。课程对比了三种攻击的本质差异，并给出登录重建 Session、设置 HttpOnly、检测 IP/UA 变化等组合防护方案。

一、 核心概念与原理

1.1 三种会话攻击的关系

攻击类型本质关键特征
Session 劫持（Session Hijacking）获取目标用户的 Session ID攻击者在用户登录后窃取其 Session ID
Session 固定（Session Fixation）会话劫持的一种特殊形式攻击者预先指定 Session ID，诱骗受害者使用该 ID 登录
Session 保持攻击（Session Persistence）在会话劫持基础上的持续性攻击攻击者拿到 Session ID 后长时间保持其有效

核心结论：无论是 Session 固定还是 Session 保持攻击，本质上都是会话劫持。只要做好会话劫持的防护，另外两种攻击在很大程度上也能被避免。

1.2 Session 固定攻击的定义

Session 固定是一种诱骗受害者使用攻击者指定的 Session ID 的攻击手段。

  • 关键词"固定"为动词，固定的是目标用户的 Session ID；
  • 与会话劫持目标一致：以受害者身份完成对目标应用程序的攻击；
  • 区别在于方式不同：会话劫持是登录后窃取 ID，Session 固定是登录前预先设定 ID。

1.3 生活案例类比

A（坏人）将汽车卖给 B，但偷偷藏了一把备用钥匙。B 买了车却没换锁，于是 A 半夜就能用备用钥匙把车开走。

  • 汽车 = 目标应用系统
  • 备用钥匙 = 攻击者预先提供的 Session ID
  • 没换锁 = 服务端登录后未重置 Session ID

二、 技术细节与协议分析

2.1 Session 固定攻击流程

步骤操作主体动作说明
1攻击者通过某种手段重置目标用户的 Session ID保证攻击者知道该 ID，并确保受害者一定会使用该 ID
2目标用户携带攻击者设定的 Session ID 登录站点登录成功即劫持成功
3服务端不重置 Session ID这是攻击成功的必要条件
4攻击者使用同一 Session ID 访问应用双方均可访问，劫持完成

难点：第一步——如何保证目标用户使用攻击者提供的 Session ID。

2.2 Session ID 的传递载体与攻击可行性

载体方式攻击可行性原因
保存在 Cookie 中较难实现攻击者难以跨域写入受害者 Cookie
保存在 URL 参数 中较易实现只需诱导用户打开带指定 Session ID 的 URL 即可

2.3 Session 固定攻击的必要条件

  • 目标用户使用攻击者指定的 Session ID 登录；
  • 目标 Web 系统不再生成新的 Session ID（登录前后 Session ID 不变）。

核心防护点即围绕此条件展开：只要服务端在登录后重新生成 Session ID，攻击者所持有的旧 ID 即失效。

2.4 Session 保持攻击原理

Session 保持攻击强调的是持续性，存在一个核心悖论：

  • 理论：Session 有有效生命周期（如 Tomcat 默认 30 分钟），用户长时间无活动则服务端销毁 Session；
  • 悖论：若 Session 一直未失效，攻击者拿到 Session ID 后即可长期窃取；
  • 关键：攻击者若能一直持有一个有效的 Session ID，理论上攻击时间可以无限长。

2.5 Session 保持的实现机制

机制一：间歇性刷新页面（保持 Session 存活）

  • 攻击者通过程序间歇性刷新目标页面，让服务端认为"用户还活着"，从而不销毁 Session；
  • 服务端对活动状态的 Session 通常不主动销毁；
  • 此时 Session 沦为攻击者的永久性后门，可随时访问。

机制二：设置 Cookie/Session 的失效时间

  • 应用出于用户体验考虑，常设置"只要用户活着就不让 Session 失效"；
  • 攻击者可模拟用户存活状态，使 Session 长时间存活；
  • 亦可为 Cookie 设置远期失效时间（如 2038 年），将原本浏览器关闭即失效的 Cookie 持久化为第三方 Cookie。

三、 实践应用与配置命令

3.1 防护方案一：登录时重建 Session（针对 Session 固定）

// 登录成功后，使原 Session 失效并重建
HttpSession session = request.getSession(false);
if (session != null) {
    session.invalidate();   // 使原有 Session 失效
}
HttpSession newSession = request.getSession(true);  // 生成新的 Session
// 重建后 ID 重新生成，仅目标用户可用，攻击者持有的旧 ID 失效

3.2 防护方案二：设置 HttpOnly（防止 Cookie 被 JS 窃取）

// 在服务器端为 Cookie 添加 HttpOnly 头
response.addHeader("Set-Cookie", "JSESSIONID=xxx; HttpOnly");
// 本地存储的 Cookie 信息将无法被客户端脚本访问，降低 XSS 窃取风险

3.3 防护方案三：保持 Session 长时间存活的攻击代码示例（理解攻击以做好防御）

<!-- 攻击者通过 IFRAME + 定时任务保持 Session 存活 -->
<iframe id="frame1" src=""></iframe>
<script>
  var url = "https://target.example.com/bbs";
  function keepAlive() {
    document.getElementById("frame1").src = url + "?r=" + Math.random();
  }
  // 每隔 6 秒刷新一次，向服务端表明"用户还活着"
  window.setInterval(keepAlive, 6000);
</script>

3.4 防护方案四：Cookie 持久化攻击示例

// 攻击者将 Cookie 失效时间设为远期，持久化到本地
document.cookie = "JSESSIONID=xxx; expires=Thu, 31 Dec 2038 23:59:59 GMT; path=/";
// 原本浏览器关闭即失效的 Cookie 变为长期有效的第三方 Cookie

3.5 Session 保持攻击的防护组合方案

防护手段实现方式用户体验影响
强制失效一定时间后（如 3 天）强制销毁 Session，要求重新登录较大，正常用户也需频繁登录
检测客户端变化当用户 IP 或 User-Agent（浏览器代理信息）发生变化时，强制销毁当前 Session 并要求重新登录较小，仅环境变化时触发
单用户单 Session每个用户只允许拥有一个有效 Session较大，多设备登录受限
降低有效期将 Session 有效期调低，闲置过久即重置中等

推荐组合：以"检测 IP / User-Agent 变化"为主，配合"登录时重建 Session"与"HttpOnly"，既保证安全性又兼顾用户体验。

四、 重点与难点提示

  • 考点 1：Session 固定与会话劫持的区别——前者是登录前指定 ID，后者是登录后窃取 ID。
  • 考点 2：Session 固定攻击成功的必要条件——服务端登录后不重置 Session ID（登录前后 Session ID 不变）。
  • 考点 3：Session ID 通过 URL 参数传递时，Session 固定攻击更易实现；通过 Cookie 传递则较难。
  • 考点 4：Session 保持攻击的本质是在会话劫持基础上的持续性攻击，关键在于让服务端认为"用户还活着"。
  • 考点 5：三种攻击的根因都是会话劫持，做好会话劫持防护即可大幅降低另两种攻击风险。
  • 易错点：invalidate() 是使 Session 失效的正确方法，而非简单的"重置"。
  • 面试题：
    1. 简述 Session 固定攻击的原理及防护方案。
    2. 如何防止 Session 保持攻击？请给出至少两种组合防护方案。
    3. 为什么说 Session 固定和 Session 保持攻击本质都是会话劫持？
    4. HttpOnly 标志在 Session 防护中的作用是什么？

五、 课后疑问/遗留问题

  1. 当 Session ID 通过 URL 参数传递时，如何在不影响用户体验的前提下彻底规避 Session 固定风险？（是否应全面禁用 URL 重写机制？）
  2. "检测 IP / User-Agent 变化"方案在移动端切换基站或NAT 网关场景下是否会误伤正常用户？如何优化？
  3. 单用户单 Session 限制下，如何优雅支持多设备登录（如办公区与家中电脑）且不牺牲安全性？
  4. 后续课程是否会涉及 Token 机制（如 JWT） 相较于 Session 的安全性对比？
最近更新:
Contributors: yangwenguang