Session-Cookie 机制：从原理到攻防实战

Session-Cookie 这套机制，说白了就是 Web 应用用来记住“你是谁”的老办法。我做了这么多年安全，见过太多团队在这上面栽跟头。今天咱们就把它的工作原理、常见攻击手法，以及怎么防御，一次性讲透。

一、Session-Cookie 工作原理

HTTP 协议本身是无状态的。你想想看，每次请求都是独立的，服务器根本不知道两次请求是不是同一个人发的。那怎么办？Cookie 和 Session 就是来解决这个问题的。

基本流程是这样的：

用户登录成功后，服务器生成一个唯一的 Session ID
服务器把 Session ID 存到 Cookie 里，通过响应头 Set-Cookie 发给浏览器
浏览器后续每次请求都会自动带上这个 Cookie
服务器根据 Session ID 找到对应的 Session 数据，就知道你是谁了

我习惯把 Session 比作“储物柜”，Cookie 就是“柜子钥匙”。钥匙交给用户，柜子留在服务器端。这样敏感数据不会暴露给客户端，安全性相对好一些。

核心要点：Session 数据存在服务端，Cookie 只存 Session ID。千万别把用户密码、身份证号这些敏感信息直接塞 Cookie 里。

来看一个简单的 Node.js 实现示例：

// 使用 express-session 中间件
const session = require('express-session');

app.use(session({
  secret: 'your-secret-key',  // 用于签名 Session ID
  resave: false,
  saveUninitialized: true,
  cookie: {
    httpOnly: true,   // 禁止 JavaScript 访问
    secure: true,     // 仅 HTTPS 传输
    maxAge: 24 * 60 * 60 * 1000  // 24 小时过期
  }
}));

// 登录成功后设置 Session
app.post('/login', (req, res) => {
  // 验证用户名密码...
  req.session.userId = user.id;
  req.session.role = user.role;
  res.send('登录成功');
});

二、Session 劫持与防御

Session 劫持，说白了就是攻击者偷走你的 Session ID，然后冒充你登录。我在项目中遇到过好几次，最严重的一次是电商平台，攻击者拿到管理员的 Session，直接改了商品价格。

常见的劫持方式有这些：

攻击方式	原理	危害等级
XSS 窃取	通过注入脚本读取 document.cookie	高
网络嗅探	在 HTTP 明文传输中截获 Cookie	高
Session 固定	诱导用户使用攻击者指定的 Session ID	中
暴力猜测	尝试枚举弱 Session ID	低（取决于实现）

我曾经踩过的坑：有个项目用了自增数字作为 Session ID，攻击者只需要改一下数字就能遍历所有用户的 Session。后来我强制要求所有 Session ID 必须用 crypto.randomBytes() 生成，长度至少 32 字节。

防御 Session 劫持，我总结了几个必做项：

设置 HttpOnly 标志：禁止 JavaScript 读取 Cookie，防 XSS 窃取
强制 HTTPS：设置 Secure 标志，防止中间人嗅探
绑定客户端特征：比如 IP 地址、User-Agent，但别太严格，否则正常用户也会受影响
定期轮换 Session ID：登录成功后重新生成，防止 Session 固定攻击
设置合理的过期时间：别让 Session 永久有效

// 登录成功后重新生成 Session ID
app.post('/login', (req, res) => {
  // 验证用户名密码...
  req.session.regenerate((err) => {
    if (err) {
      return res.status(500).send('服务器错误');
    }
    req.session.userId = user.id;
    res.send('登录成功');
  });
});

三、CSRF 攻击与 Token 防御

CSRF（跨站请求伪造）和 Session 劫持不一样。Session 劫持是偷你的钥匙，CSRF 是利用你手里的钥匙去开门。

举个例子：你登录了银行网站，Session 还在有效期内。这时候你打开了一个恶意网站，它偷偷发了一个请求去转账。因为浏览器会自动带上银行的 Cookie，服务器一看 Session 有效，就执行了转账操作。

为什么会这样？因为服务器没法区分这个请求是用户主动发的，还是被恶意网站诱导的。

关键区别：Session 劫持是攻击者冒充用户，CSRF 是攻击者利用用户自己的身份去执行操作。

防御 CSRF 最有效的方法就是 Token 机制。原理很简单：

服务器生成一个随机 Token，存在 Session 里
在表单页面里嵌入这个 Token
提交请求时带上 Token
服务器验证 Token 是否匹配

恶意网站没法获取这个 Token，因为同源策略禁止跨域读取页面内容。

// 生成 CSRF Token
const csrfToken = crypto.randomBytes(32).toString('hex');
req.session.csrfToken = csrfToken;

// 在表单中嵌入 Token
// <input type="hidden" name="_csrf" value="<%= csrfToken %>">

// 验证 Token
app.post('/transfer', (req, res) => {
  const { _csrf, amount, toAccount } = req.body;
  
  if (_csrf !== req.session.csrfToken) {
    return res.status(403).send('CSRF Token 验证失败');
  }
  
  // 执行转账...
});

除了 Token，还有几种常见的防御手段：

防御方式	原理	优缺点
SameSite Cookie	限制跨站请求携带 Cookie	简单有效，但老浏览器不支持
Referer/Origin 验证	检查请求来源	容易被绕过，不推荐单独使用
二次验证	敏感操作要求输入密码或验证码	用户体验差，但安全性高
Token 机制	随机 Token 验证请求合法性	最常用，配合框架中间件使用

我的建议：别自己手写 CSRF 防御逻辑。Express 有 csurf 中间件，Spring Security 内置了 CSRF 保护，直接用现成的。自己实现容易漏掉细节，比如 Token 的过期策略、刷新机制等。

嗯，这里要注意一点：Token 一定要和用户 Session 绑定。我见过有人把 Token 存在全局变量里，所有用户共用同一个 Token，那跟没防御一样。

下面这张图展示了 Session-Cookie 机制的核心流程和攻击面：

重要提醒：CSRF Token 不要通过 Cookie 传递！Token 的目的是验证请求是否来自合法页面，如果 Token 也在 Cookie 里，那恶意网站照样能拿到。Token 应该放在表单隐藏域、请求头（比如 X-CSRF-Token）或者 Authorization 头里。

最后说一句，Session-Cookie 机制虽然经典，但在现代分布式架构下有不少局限性。比如 Session 同步问题、跨域问题等。后面我们会讲到 JWT 和 OAuth 2.0，它们在某些场景下是更好的选择。不过，理解 Session-Cookie 依然是安全基础，很多攻击手法和防御思路都是相通的。

📚 课程目录

Session-Cookie 机制：从原理到攻防实战

一、Session-Cookie 工作原理

二、Session 劫持与防御

三、CSRF 攻击与 Token 防御