【安全研发】CSRF (跨站请求伪造) 深度复盘与防御体系
记录时间： 2026-01-21
核心逻辑： 盗用身份。黑客拿不到我的 Cookie，但他能利用浏览器的自动机制，"借刀杀人"操作我的账户。
1. 攻击原理：浏览器是"内鬼"
- 机制： 只要向目标域名发请求，浏览器会自动带上该域名的 Cookie。
- 场景： 用户登录了银行网站，Cookie 尚未失效。用户在黑客网站点击了一个诱导链接/图片。
- 后果： 黑客构造的转账请求被浏览器自动加上了 Cookie，服务器认为是用户本人操作，转账成功。
2. 防御体系：三道防线
2.1 黄金标准：CSRF Token
- 原理： 除了 Cookie，要求请求必须携带一个随机生成的、黑客无法伪造的 Token（通常放在 Header 或 Hidden Field 中）。
- 逻辑： Cookie 是浏览器自动带的（黑客能利用），Token 是前端代码手动带的（黑客跨域拿不到）。
- 适用性： 所有 POST/PUT/DELETE 等改变数据的请求。
2.2 现代标准：SameSite Cookie (Lax)
- 原理： 在 Set-Cookie 时指定
SameSite属性，告诉浏览器："如果是跨站请求，别带我"。 - 执法者： 浏览器。
- 规则（Lax 模式）：
- 链接跳转 (Top-level Navigation)： 允许带 Cookie（为了用户体验，免登录）。
- 后台请求 (POST/Img/Iframe)： 禁止带 Cookie。直接阻断 CSRF。
2.3 辅助防线：Origin / Referer 校验
- 原理： 检查 HTTP 头里的来源地址。如果来源不是自家域名，直接拒绝。
- 缺点： Referer 可能被伪造或被隐私插件屏蔽，只能作为兜底。
3. 深度思考：SameSite 与 RESTful 的强制绑定 (Critical!)
这是本次复盘的核心洞察：
如果使用 SameSite=Lax 作为防御手段，后端必须 严格遵守 RESTful 规范。
- 漏洞场景： 假如后端写了一个违规接口
GET /transfer?money=1000（用 GET 请求修改数据）。 - 攻击向量： 黑客发一个链接
<a href="http://bank/transfer...">点我看美女</a>。 - 穿透逻辑： 用户点击链接 -> 触发顶级导航 (Top-level Navigation) -> 浏览器判断这是 GET 请求且地址栏变了 -> Lax 规则允许带 Cookie -> 攻击成功！
- 结论： GET 请求必须是只读（Safe）的。 凡是涉及数据修改的操作，必须用 POST/PUT/DELETE，否则
SameSite=Lax形同虚设。