# CSRF 跨站请求伪造与 Token 防护实践 > CSRF：Cross-Site Request Forgery，跨站请求伪造；OWASP Top10 经典漏洞 > 一句话原理：**利用用户当前浏览器已登录的身份，诱导用户访问恶意页面，在用户不知情的情况下，自动发起跨站请求执行业务操作**。攻击者拿不到Cookie明文，而是直接复用浏览器自动携带的Cookie/会话凭据。 ## 一、核心攻击条件（三者同时满足） 1. 目标站点**仅依靠Cookie/Session识别身份**，请求无额外校验凭证 2. 浏览器访问恶意页面时，自动带上目标网站Cookie 3. 业务接口存在**无状态的修改操作**：修改密码、转账、绑定手机号、新增管理员、发布内容 > 区分 CSRF 和 XSS： > - CSRF：**借用你的身份**，不能读取返回内容；不需要注入代码，利用浏览器自动带Cookie > - XSS：**在页面内执行脚本**，可以读取Cookie、直接发起请求，危害更大 ## 二、CSRF 攻击流程 1. 用户登录业务网站A，浏览器保存A的session cookie 2. 用户不关闭浏览器，打开恶意网站B 3. B页面包含隐藏表单/JS，自动向A站点提交请求 4. 浏览器自动带上A的Cookie，A服务端认为是用户本人操作，执行修改 示例恶意表单（自动提交） ```html
``` ## 三、识别测试方法（授权测试） 1. 确认接口：修改类接口，是否仅依赖Cookie识别身份 2. 构造独立HTML页面，放到其他域名打开，保持目标网站登录状态 3. 访问恶意HTML页面，观察业务操作是否被执行 > 如果成功执行，代表存在CSRF漏洞 ### 快速判断要点 - GET请求可执行修改操作（高危，GET天生容易触发CSRF） - POST表单无额外校验token，只依靠cookie鉴权 - 接口没有校验来源（Referer/Origin） ## 四、防护方案（优先级从高到低） ### ✅ 方案1：CSRF Token（行业标准首选） 核心思想：**每次请求附加一个服务端生成的随机Token，放在表单/请求头；服务端校验Token合法性，Token绑定当前用户session** 1. 用户会话建立时，服务端生成随机csrfToken，存入session 2. 页面渲染时，Token嵌入表单隐藏域，或放到前端localStorage（前端接口放Header） 3. 提交请求，带上Token；后端校验：token是否存在、是否与当前session匹配 4. Token一次性/短期有效，不可预测 > 传递位置推荐： > - 表单：`` > - Ajax：放到请求头 `X-CSRF-Token: xxx` > 关键：**Token不能放在Cookie里**，否则依然可以被自动携带绕过防护。 ### ✅ 方案2：Origin / Referer 请求头校验（辅助防护，不能单独作为唯一防护） 浏览器跨站请求会带上Origin（优先）、Referer头。 后端校验：请求来源域名是否属于本站可信域名列表。 局限： 1. 部分浏览器/代理可丢弃Referer；移动端、部分隐私模式会清空Referer 2. 只能做辅助，**不能单独用来防御CSRF** ### ✅ 方案3：SameSite Cookie 属性（现代浏览器原生防御，推荐搭配Token一起使用） Cookie新增SameSite属性，控制跨站场景是否自动携带Cookie - `SameSite=Strict`：任何跨站请求，都不会携带Cookie，防护最强 - `SameSite=Lax`（现代浏览器默认）：GET跨站不携带，POST跨站默认不带；兼容性好，推荐优先配置 - `SameSite=None`：跨站可携带Cookie，**必须搭配Secure（HTTPS）** > 注意：老旧浏览器不支持SameSite，因此只能作为增强手段，**不能替代CSRF Token** ### ✅ 方案4：高危操作增加二次认证（强业务校验） 修改密码、资金操作、绑定手机：增加短信验证码、邮箱验证码、MFA。 即使CSRF成功发起请求，没有验证码无法完成操作。 ## 五、常见误区 1. ❌ 只用Referer校验，不使用Token：存在Referer丢失场景，防护不完整 2. ❌ GET请求不能CSRF：GET最容易被图片/iframe触发，**修改类业务禁止使用GET** 3. ❌ 接口是JSON就不会CSRF：简单JSON请求依然会触发；只有带自定义请求头的跨站请求会触发预检OPTIONS，但依然建议加token 4. ❌ Token存在Cookie里面：攻击者页面会自动带上cookie中的token，防护失效 5. ❌ CSRF可以读取响应数据：CSRF只能发起请求，无法读取跨站响应；读取数据需要XSS ## 六、审计检查清单 - [ ] 所有**状态修改接口（POST/PUT/DELETE）**是否携带CSRF Token并后端校验 - [ ] Token是否绑定当前用户Session，不可预测 - [ ] 修改类接口是否使用GET请求（禁止） - [ ] Cookie是否配置SameSite属性 + Secure（HTTPS站点） - [ ] 是否校验Origin/Referer作为辅助防护 - [ ] 高危操作（改密、资金）是否增加短信/验证码二次校验 ## 七、漏洞笔记模板（适配你之前格式） 漏洞名称：跨站请求伪造 CSRF 漏洞类型：会话管理缺陷 风险等级：中危（高危业务场景升级为高危） 前置权限：已登录用户会话 原理：业务修改接口仅依赖Cookie识别用户身份，无CSRF Token校验；诱导用户访问恶意页面，浏览器自动携带Cookie发起跨站请求，执行修改操作。 复现步骤： 1. 用户登录目标网站，保持会话 2. 在另一域名打开构造好的恶意html页面 3. 页面自动发起POST请求，业务操作成功执行 缓解方案：临时增加Referer/Origin白名单校验 永久修复：接入CSRF Token校验；Cookie配置SameSite=Lax；修改类接口禁止GET；高危操作增加短信验证码 ## 八、SIEM/WAF检测要点 CSRF属于业务逻辑漏洞，WAF很难直接检测攻击；防护重心在服务端代码。 可监控行为： - 同一用户短时间，从完全不同来源域名发起敏感修改操作 - 大量请求缺少CSRF Token