Session-Cookie 机制：从原理到攻防实战
Session 和 Cookie，这对组合可以说是 Web 认证的「老搭档」了。我最早接触它们是在做一个企业 OA 系统的时候，当时被 CSRF 坑过一次，从那以后就再也不敢小看这两个小东西了。
说白了，HTTP 是无状态的。你登录了一次，服务器怎么记住你是谁？答案就是：让客户端帮忙「记住」一个凭证，然后每次请求都带上它。Cookie 就是这个凭证的载体，而 Session 则是服务端保存的用户状态。
Session 工作原理
Session 的核心思路很简单：服务端存状态，客户端存 ID。
用户登录成功后，服务器会创建一个 Session 对象，里面存着用户 ID、角色、过期时间等信息。然后生成一个唯一的 Session ID，通过 Set-Cookie 响应头发给浏览器。浏览器下次请求时，自动带上这个 Cookie，服务器根据 Session ID 找到对应的 Session 数据，就知道你是谁了。
关键流程：
- 用户提交登录凭证（用户名+密码）
- 服务端验证通过，创建 Session，生成 Session ID
- 服务端返回 Set-Cookie 头：
Set-Cookie: session_id=abc123; Path=/; HttpOnly; Secure - 浏览器后续请求自动携带 Cookie：
Cookie: session_id=abc123 - 服务端根据 session_id 查找 Session，获取用户信息
这里有个细节——Session 数据存在哪里？我见过三种常见方案：
| 存储方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 内存（本地） | 速度快，实现简单 | 重启丢失，无法水平扩展 | 单机应用、开发环境 |
| Redis | 持久化，支持集群，高性能 | 多一次网络开销 | 生产环境、分布式系统 |
| 数据库 | 持久化，可跨语言 | 读写慢，IO 瓶颈 | 低频访问、管理后台 |
我个人习惯用 Redis 存 Session。为什么呢？因为内存方案在服务器重启时 Session 全丢了，用户得重新登录，体验很差。而 Redis 可以持久化，还能做 Session 共享，多台服务器都能读到同一个 Session。
避坑指南：我曾经在生产环境遇到过 Session 风暴——用户量突然暴增，Redis 连接池被打满，导致大量请求超时。后来加了限流和 Session 预创建才解决。建议给 Session 设置合理的过期时间，别太长也别太短，一般 30 分钟到 2 小时比较合适。
Cookie 属性与安全
Cookie 可不是随便设个 key-value 就完事了。它的每个属性都和安全息息相关。我见过太多因为 Cookie 属性没配好导致的安全事故了。
来看一个标准的 Cookie 设置：
Set-Cookie: session_id=abc123;
Domain=.example.com;
Path=/;
Max-Age=3600;
HttpOnly;
Secure;
SameSite=Lax每个属性的作用：
| 属性 | 作用 | 安全建议 |
|---|---|---|
| Domain | 指定哪些域名可以接收 Cookie | 尽量缩小范围，不要用顶级域名 |
| Path | 指定哪些路径可以携带 Cookie | 用 / 或具体路径 |
| Max-Age / Expires | Cookie 存活时间 | 会话 Cookie 不设持久化时间 |
| HttpOnly | 禁止 JavaScript 读取 Cookie | 必须开启，防 XSS 窃取 |
| Secure | 仅通过 HTTPS 传输 | 必须开启，防中间人攻击 |
| SameSite | 控制跨站请求是否携带 Cookie | 建议设为 Lax 或 Strict |
嗯，这里重点说一下 HttpOnly。你想想看，如果 Cookie 能被 JavaScript 读取，攻击者通过 XSS 注入一段脚本就能拿到你的 Session ID，然后伪造请求。开启 HttpOnly 后，document.cookie 就看不到这个 Cookie 了，XSS 攻击者只能干瞪眼。
警告：千万不要把敏感信息直接放在 Cookie 里！我见过有人把用户密码明文存在 Cookie 里，说是「方便下次自动填充」——这简直是给攻击者送人头。Cookie 只存 Session ID，用户数据放服务端 Session 里。
CSRF 攻击与防护
CSRF（跨站请求伪造）是我觉得最「阴险」的攻击方式之一。它不偷你的 Cookie，而是利用你的 Cookie 帮你「办事」。
举个例子：你登录了银行网站 A，浏览器里有了 A 的 Session Cookie。然后你访问了一个恶意网站 B，B 页面里藏了一个请求：
<img src="https://bank.com/transfer?to=attacker&amount=10000" style="display:none" />浏览器会自动带上 bank.com 的 Cookie，服务器一看 Session 有效，就执行了转账操作。整个过程你完全不知情。
为什么会这样？因为 Cookie 的携带机制是「自动的」——只要请求目标域名匹配，浏览器就会带上对应的 Cookie，不管这个请求是从哪里发起的。
防护方案对比
| 方案 | 原理 | 优点 | 缺点 |
|---|---|---|---|
| CSRF Token | 服务端生成随机 Token，表单提交时校验 | 通用性强，安全性高 | 需要前后端配合，增加开发成本 |
| SameSite Cookie | 浏览器限制跨站请求携带 Cookie | 配置简单，浏览器原生支持 | 旧浏览器不支持，部分场景受限 |
| Referer/Origin 校验 | 检查请求来源是否合法 | 零侵入，服务端即可完成 | Referer 可能被篡改或丢失 |
| 二次验证 | 敏感操作要求输入密码或验证码 | 安全性最高 | 用户体验差 |
我个人最推荐的做法是 CSRF Token + SameSite=Lax 双保险。Token 作为核心防护，SameSite 作为兜底。这样即使 Token 校验有漏洞，SameSite 也能挡住大部分跨站攻击。
实战经验：我曾经在一个项目中只用了 Referer 校验，结果被绕过——攻击者通过 <meta> 标签伪造了 Referer。后来改成 Token 方案才彻底解决。记住：不要依赖客户端能控制的任何信息来做安全校验。
核心逻辑流程图
下面这张图展示了 Session-Cookie 机制从登录到请求验证的完整流程，以及 CSRF 攻击的切入点：
总结一下关键点
- Session 存服务端，Cookie 只存 ID，别把用户数据塞 Cookie 里
- HttpOnly 和 Secure 必须开，这是底线
- SameSite 能防大部分 CSRF，但不能完全依赖它
- CSRF Token 是业界标准方案，实现起来也不复杂
- 敏感操作（改密码、转账）一定要加二次验证
嗯，Session-Cookie 机制看起来简单，但坑不少。我每次做新项目都会重新审视一遍 Cookie 的配置，毕竟安全这东西，多一分谨慎就少一分风险。