CSRF 验证是什么
CSRF（Cross-Site Request Forgery，跨站请求伪造）的本质是：浏览器会自动携带目标站点的会话 Cookie，攻击者只要诱导受害者在登录状态下发出一个构造好的请求，就能以受害者身份执行状态变更操作。判断核心在于服务端是否只凭 Cookie 就受理请求，还是额外校验了 CSRF Token、SameSite 属性或自定义请求头。验证时选低影响、可撤销的操作，例如给自己加一个标签，先正常提交建立基线，再移除 Token 或自定义头重放，看服务端是否仍然受理。只验证到受理与否，不实际造成业务后果。
基本信息
| 风险类型 | 跨站请求伪造，CWE-352 |
|---|---|
| 判断点 | 是否校验 CSRF Token 或同源标记 |
| 关注对象 | 表单、AJAX 接口、一键操作链接 |
| 缓解手段 | 同步令牌、双提交 Cookie、SameSite=Lax/Strict |
| 验证边界 | 只验证受理或拒绝，不造成真实业务变更 |
典型使用场景
- 改密与绑定：修改密码、绑定手机号、改邮箱等敏感表单
- 资金与额度：转账、下单、提现类接口（属高风险，仅做设计核查）
- 权限管理：加权限、改角色、邀请成员
- 一键操作：订阅、点赞、删除这类无二次确认的链接
- JSON 接口：Content-Type 为 application/json 的接口常被误认为天然免疫
验证步骤
验证步骤
1. 选一个低影响、可撤销的状态变更操作作为验证对象
2. 正常提交一次，记录请求头、Cookie 与 Token 位置
3. 移除请求中的 Token 或自定义头后重新提交
4. 观察服务端是否仍受理（与正常请求响应对比）
5. 记录请求构造方式与结果，恢复测试数据防护强度对照
| 防护方式 | 有效性 | 说明 |
|---|---|---|
| 无 Token 校验 | 无 | 只依赖 Cookie，跨站请求会被受理 |
| SameSite=Lax | 部分 | 能挡大部分跨站 POST，顶层 GET 导航仍带 Cookie |
| SameSite=Strict | 较强 | 跨站场景不带 Cookie，可能影响外站跳转体验 |
| 同步令牌 | 较强 | Token 随表单或头部提交，服务端逐次比对 |
| 双提交 Cookie | 较强 | Cookie 与请求参数中的 Token 需一致 |
修复视角：同步令牌（每会话或每表单）与双提交 Cookie 是主流方案；SameSite 属性可显著降低风险，但需结合兼容性与跳转场景评估，不能单独当作修复。
不要在验证中使用转账、删除、发消息这类高影响操作，容易造成真实业务副作用；优先选择可撤销、可回滚的动作。