1、会话管理基础：Cookie与Session原理、无状态协议的本质、会话劫持攻击模型
各位同学，咱们今天聊点实在的。会话管理这东西，说白了就是让服务器能认出「你是谁」。HTTP 本身是个健忘的家伙——它不记得你上一秒干了什么。这就是所谓的无状态协议。嗯，这里要注意，无状态不是缺陷，是设计。但现实业务需要状态，于是就有了 Cookie 和 Session。
1.1 无状态协议的本质
HTTP 为什么无状态？因为早期 Web 就是用来浏览静态文档的。你打开一个页面，服务器把文件扔给你，连接就断了。下次你再请求，服务器根本不记得你。我刚开始做 Web 开发时，觉得这设计太「傻」了。后来才明白，无状态让服务器可以轻松横向扩展——每台机器都是平等的，谁处理请求都一样。
但业务需要状态。比如购物车，你得让服务器知道「这个商品是张三加的」。怎么办？给每个用户发一个「身份证」，每次请求都带上。这就是会话管理的核心思路。
核心要点：无状态是 HTTP 的基因，会话管理是在无状态之上「模拟」有状态。不要试图改变协议，而是用机制弥补。
1.2 Cookie 原理与工作机制
Cookie 是浏览器端的「小纸条」。服务器通过 Set-Cookie 响应头把纸条贴给浏览器，浏览器下次请求时通过 Cookie 请求头把纸条带回来。
我个人习惯把 Cookie 分为三类：
| 类型 | 存储位置 | 生命周期 | 典型用途 |
|---|---|---|---|
| 会话 Cookie | 内存 | 浏览器关闭即销毁 | Session ID |
| 持久 Cookie | 硬盘 | 由 Expires/Max-Age 控制 | 记住登录状态、偏好设置 |
| 安全 Cookie | 硬盘/内存 | 受 Secure/HttpOnly 限制 | 敏感信息、令牌 |
举个例子，用户登录成功后，服务器返回：
HTTP/1.1 200 OK
Set-Cookie: session_id=abc123; Path=/; HttpOnly; Secure; SameSite=Lax
浏览器收到后，后续每次请求都会带上：
GET /profile HTTP/1.1
Cookie: session_id=abc123
服务器看到 session_id=abc123，就去内存或 Redis 里查这个 ID 对应的用户信息。完美，状态恢复了。
避坑指南：我曾经在项目中遇到一个问题——Cookie 没设 HttpOnly，导致 XSS 攻击者直接用 document.cookie 偷走了所有用户的 Session ID。从那以后，我所有涉及认证的 Cookie 必加 HttpOnly 和 Secure。
1.3 Session 原理与存储模型
Session 是服务器端的「档案袋」。Cookie 只存一个 ID，真正的用户数据存在服务器上。为什么这么设计？因为 Cookie 有大小限制（4KB 左右），而且数据暴露在客户端不安全。
Session 的典型工作流程：
- 用户登录，服务器验证凭据
- 服务器创建 Session 对象，生成唯一 Session ID
- 服务器将 Session ID 通过 Cookie 返回给浏览器
- 浏览器后续请求携带 Session ID
- 服务器根据 Session ID 查找对应的 Session 数据
Session 存储在哪里？常见方案有：
- 内存存储： 单机可用，重启丢失。我早期做小项目时用过，后来被坑过一次——服务器重启，所有用户被迫重新登录。
- Redis/Memcached： 分布式场景标配。速度快，支持过期，支持集群。我现在几乎都用 Redis。
- 数据库存储： 持久化好，但读写慢。适合对数据一致性要求极高的场景。
- Cookie 直接存储： 不推荐。数据暴露在客户端，有篡改风险。
警告：Session 数据不要放太多。我见过有人把整个用户对象（包括权限列表、头像 base64）塞进 Session，结果 Redis 内存暴涨，GC 频繁，接口响应时间从 10ms 飙升到 500ms。Session 只存用户 ID 和必要标识即可，其他数据按需查询。
1.4 会话劫持攻击模型
会话劫持，说白了就是攻击者偷走你的 Session ID，然后冒充你。为什么能偷？因为 Session ID 是唯一的「身份凭证」，谁拿到谁就是「你」。
常见的劫持手段：
| 攻击方式 | 原理 | 典型场景 |
|---|---|---|
| XSS 窃取 | 通过注入脚本读取 Cookie | 评论区未过滤的脚本标签 |
| 网络嗅探 | 抓取明文 HTTP 流量中的 Cookie | 公共 WiFi 上的 HTTP 请求 |
| Session 固定 | 强制用户使用攻击者指定的 Session ID | 钓鱼链接携带固定 Session ID |
| CSRF 配合 | 诱导用户在已认证状态下执行恶意请求 | 隐藏表单提交转账请求 |
攻击模型可以抽象为三步：
- 获取： 攻击者通过某种手段拿到用户的 Session ID
- 使用： 攻击者将 Session ID 放入自己的请求中
- 冒充： 服务器认为攻击者就是合法用户，授予相应权限
你想想看，如果攻击者拿到了你的 Session ID，他能干什么？他能看你的私信、改你的密码、用你的余额下单。这就是为什么会话安全如此重要。
关键认知：会话劫持的本质是「身份凭证泄露」。防御的核心不是让凭证不可泄露（这不可能），而是让泄露的凭证不可用或快速失效。这就是后面章节要讲的令牌绑定和会话恢复。
1.5 本章知识体系图
下面这张图把本章的核心逻辑串起来了。从无状态协议出发，到 Cookie 和 Session 的协作，再到攻击者如何利用漏洞劫持会话。建议你多看几遍，理解每个箭头代表的含义。
1.6 小结与思考
这一章我们聊了三件事：
- 无状态协议的本质： HTTP 不记得你是谁，这是设计使然，不是 bug。
- Cookie 与 Session 的协作： Cookie 存 ID，Session 存数据，两者配合模拟出「有状态」的假象。
- 会话劫持攻击模型： 攻击者通过窃取 Session ID 来冒充用户，核心是「凭证泄露」。
我个人觉得，理解这三件事是做好会话安全的基础。很多同学一上来就研究 JWT、OAuth，结果连 Cookie 的 HttpOnly 和 Secure 都没搞明白，这不行。地基不牢，后面全是空中楼阁。
一个小练习：打开浏览器的开发者工具，看看你正在访问的网站设置了哪些 Cookie。哪些是会话 Cookie？哪些是持久 Cookie？有没有 HttpOnly 和 Secure 标记？动手看看，比读十遍书都管用。