CSRF 攻击是什么？如何防范？

简化版

CSRF 是攻击者诱导已登录用户在不知情时向目标网站发起请求，利用浏览器自动携带 Cookie 的特性完成伪造操作。防护方式包括 SameSite Cookie、CSRF Token、校验 Origin/Referer、重要操作二次确认，以及避免用 GET 做状态修改。

CSRF 成立通常需要：

防护方式：

CSRF 主要防的是“请求被伪造”，不是“响应被读取”。

用户登录了 A 网站，浏览器保存了 A 的 Cookie。用户又访问恶意 B 网站，B 网站中放了一个自动提交表单或图片请求，指向 A 网站的转账接口。

如果 A 网站只看 Cookie 判断用户身份，浏览器会自动带上 Cookie，A 可能误以为这是用户本人操作。

CSRF 依赖浏览器自动携带凭证。如果登录态是前端手动放到 Authorization header，普通跨站表单或图片请求通常无法自动带上这个 header，CSRF 风险会降低。

但这不代表 token 方案没有安全问题。token 如果被 XSS 窃取，同样危险。

CSRF Token 的思路是让请求必须携带攻击者拿不到的随机值。

页面加载时服务端下发 token，修改类请求必须带上 token。攻击者虽然能诱导浏览器发请求，但通常读不到目标站页面里的 token。

服务端验证 token 正确才执行操作。

面试官可能问：“SameSite 能完全替代 CSRF Token 吗？”

不能一概而论。SameSite 能显著降低跨站携带 Cookie 的风险，但兼容性、业务跨站场景和安全等级不同。高风险系统通常会组合 SameSite、Token、Origin 校验。

工程中所有状态修改接口都应该使用 POST/PUT/DELETE，并在服务端做权限和来源校验。

SameSite 判断的是 site，不等同于严格的 origin；同站不同子域仍可能是不同源。高风险 Cookie 会话通常采用多层策略：

Token 要有足够熵、绑定会话，并通过隐藏字段或自定义头返回；不要放进 URL，避免进入历史、日志和 Referer。服务端必须使用恒定时间比较并在缺失或不匹配时拒绝。

记忆钩子：CSRF 防的是“浏览器替攻击者带凭证”，所以服务端要额外验证一项攻击页面无法伪造的请求上下文。

假设用户登录银行后访问恶意页，恶意页自动提交：

<form action="https://bank.example/transfer" method="post">
  <input name="to" value="attacker">
  <input name="amount" value="10000">
</form>

POST 并不会自动安全。若会话 Cookie 可跨站携带且接口只校验 Cookie，10000 元状态变更仍可能执行。加入会话绑定的 256 位随机 Token 后，攻击页能提交表单却无法猜中 Token；再配合 SameSite 和 Origin 校验，单点配置失误也不至于直接失守。

接口还应采用幂等键和交易确认，防止用户双击、网络重试与攻击流量造成重复执行。安全测试至少覆盖跨站表单、跨站图片 GET、缺 Token、错误 Token、合法同源请求和 XSS 场景；XSS 能以站内脚本身份发请求，因此必须独立修复。

对于多标签页和后退操作，按请求轮换 Token 可能造成可用性问题；按会话 Token 更易用但暴露窗口更长。选型要同时考虑安全等级、并发请求和表单历史行为。