课程笔记：Session 认证与会话劫持

课程名称：计算机网络应用 核心摘要：本讲围绕 Session 安全展开，首先厘清认证与授权、单因素与多因素认证等基础概念，说明 HTTP 无状态协议引入 Session/Cookie 机制的必要性，剖析 Session ID 作为身份凭证在 Cookie 中的存储方式；进而系统讲解会话劫持（Session Hijacking）的原理、获取 Session ID 的多种手段，并给出 HttpOnly、Secure 配合 HTTPS 的防御方案。

一、核心概念与原理

1.1 认证与授权

概念	英文	目的	生活化类比
认证（Authentication）	Authentication	认出用户"是谁"	用钥匙开锁进入房间
授权（Authorization）	Authorization	决定用户"能做什么"	进房后可看电视/睡觉等不同权限

凭证（Credential）：系统中识别用户身份所携带的信息，类比"钥匙"。
登录功能：对应"开锁过程"，即认证过程。
权限差异示例：房屋主人（管理员）可任意活动；邻居张三（普通用户）只能在客厅看电视，不能进卧室睡觉。

1.2 单因素认证与多因素认证

类型	说明	典型场景
单因素认证	仅一种凭证（如用户名+密码）进行鉴定	论坛、问答、阅读类 App
多因素认证	两种或多种凭证组合验证	手机网银、微信/支付宝支付

常见凭证形式：密码、指纹、虹膜、人脸识别、声音、手机验证码。
权衡原则：验证方式越多 → 安全性越高 → 用户体验越差。涉及资金交易时优先保证安全性，普通应用可降低认证因素与频率以提升体验。

HTTP 是无状态协议：服务器无法区分请求来源，会导致张三添加的商品进入李四的购物车等问题。
为此引入两大机制：

机制	维护位置	创建者	作用
Session	服务端	服务端	维护用户会话状态信息
Cookie	客户端	服务端创建后下发	保存 Session ID 等凭证

Session ID：用户登录成功后在服务端创建的会话唯一标识，作为个人身份凭证。
Session ID 存储于 Cookie 中，浏览器每次请求自动携带，服务端据此识别用户。
主流认证方式：用户名+密码登录 → 换取 Token；传统项目甚至直接使用用户名密码，无 Token。

二、技术细节与协议分析

2.1 Session 劫持（Session Hijacking）原理

定义：通过一定手段窃取目标用户的 Session ID，攻击者以其合法身份访问系统，绕过登录直接获取敏感数据。
又称：当 Session ID 保存在 Cookie 中时，亦称 Cookie 劫持 / Cookie 窃取。
核心风险：Session ID 在生命周期内一旦被窃取，等同于账户丢失——无需用户名密码即可获得对应账户的全部权限数据。

2.2 会话劫持攻击流程

步骤	主体	动作	说明
1	目标用户	登录站点	如 admin 或普通用户
2	服务端	生成 Session ID	下发唯一会话标识存入 Cookie
3	攻击者	获取 Session ID	通过 XSS、嗅探、木马等手段
4	攻击者	冒用身份访问	拿 admin 的 Session ID 即以 admin 身份操作

2.3 获取 Session ID 的常见手段

手段	方式	可行性/特点
暴力破解	逐一尝试各种 Session ID 直至破解	笨拙、实施性低
预测算法	已知服务端生成算法，或 ID 采用非随机方式（如累加）可被计算	需掌握生成规律
网络嗅探	使用抓包工具分析会话数据包	当前主流方式之一
植入木马	在目标本地植入木马窃取 Cookie	成本高但收益大
XSS 攻击	跨站脚本攻击窃取 Cookie 中的 Session ID	常见且高效

说明：前两种因笨拙、可实施性低较少使用；当前以网络嗅探、木马植入、XSS 攻击居多。对于数据价值高的目标（如银行），攻击者愿意投入较高成本实施攻击。

三、实践应用与配置命令

3.1 防御策略一：HttpOnly 属性

作用：禁止 JavaScript 读取 Cookie，防御 XSS 窃取 Session ID。
配置位置：推荐在 Nginx 中全局设置，亦可于 Java Web 程序中设置。

# Nginx 添加消息头（推荐全局生效）
response set_header Set-Cookie "key=value; HttpOnly";

// Java Web 程序中设置
session.setHttpOnly(true);   // 通过 Session/Cookie 接口设置
cookie.setHttpOnly(true);

3.2 防御策略二：Secure 属性 + HTTPS

背景：HTTP 明文传输易被网络嗅探、ARP 攻击等监控截获。
Secure 属性：设置后浏览器仅在 HTTPS 下才发送该 Cookie，非 HTTPS 不发送。
效果：明文访问 → 密文访问，嗅探无法获取明文 Cookie。

# Nginx 增加 Secure 消息头（HTTPS 场景）
response set_header Set-Cookie "key=value; HttpOnly; Secure";

// Java Web 程序中追加 Secure 属性
cookie.setHttpOnly(true);
cookie.setSecure(true);   // 仅 HTTPS 下发送

小结：HttpOnly 防 XSS 窃取；Secure + HTTPS 防网络嗅探。两者配合使用，配置简单，多数攻击可通过基本防护避免。

四、重点与难点提示

考点①：区分认证（你是谁）与授权（你能做什么）——两者英文相近易混淆，是常见面试题。
考点②：Session 与 Cookie 的关系——Session 在服务端、Cookie 在客户端；Cookie 承载 Session ID。
考点③：Session ID 即身份凭证——窃取 Session ID 等同于窃取账户，无需用户名密码。
考点④：会话劫持的获取手段——暴力破解、预测、网络嗅探、木马、XSS 五类，需能区分主流方式。
易错点：HttpOnly 防的是 XSS，Secure 防的是嗅探/中间人，二者防护目标不同，不可混淆。
面试题：为什么 HTTP 无状态需要引入 Session？如何防御会话劫持？

五、课后疑问/遗留问题

本讲提及的 Session 固定攻击与 Session 保持攻击具体原理与防御方式如何？（预告后续课程）
Token/JWT 与传统 Session 认证的差异及各自安全风险对比？
多因素认证在企业级系统中的落地实现方案（如 Spring Cloud OAuth2）如何设计？
会话超时（Session Timeout）机制如何配合 Session 劫持防御？