CSRF攻击利用浏览器自动携带用户认证信息的特点，诱导用户执行非本意操作。例如，用户登录银行网站后访问恶意页面，页面中的隐藏请求会携带Cookie自动发起转账。防御方法包括：使用Anti-CSRF Token验证请求合法性；检查Referer或Origin头确认来源；设置SameSite Cookie属性限制跨站发送；采用双重提交Cookie机制。开发中需确保敏感操作启用防护，API避免自动携带凭证，并在所有关键页面启用完整保护措施。
CSRF（Cross-Site Request Forgery，跨站请求伪造）是一种攻击方式，攻击者诱导用户在已登录的Web应用中执行非本意的操作。由于浏览器会自动携带用户的认证信息（如 Cookie），攻击者可以伪造请求，让用户在不知情的情况下提交敏感操作，比如修改密码、转账或删除数据。
CSRF 攻击是如何工作的？
假设你登录了银行网站 bank.com，浏览器保存了你的会话 Cookie。攻击者创建一个恶意页面，里面包含一个隐藏的表单或图片标签，指向银行的转账接口：
<img src="https://bank.com/transfer?to=attacker&amount=1000" />当你访问这个恶意页面时，浏览器会自动带上你在 bank.com 的登录凭证发起请求，从而完成转账，而你完全不知情。
如何有效防御 CSRF？
防御的核心是确保每个敏感请求都来自合法的用户操作，而不是被第三方诱导发起。以下是几种常用方法：
- 使用 Anti-CSRF Token：服务器在返回页面时嵌入一个随机生成的 token（通常放在表单隐藏字段或自定义 HTTP 头中）。每次提交请求时，服务器验证该 token 是否匹配。由于攻击者无法获取 token，伪造请求将失败。
- 检查 Referer 或 Origin 头：服务器可以检查请求的 Referer 或 Origin 字段，确认请求是否来自可信域名。虽然可绕过，但作为辅助手段有一定效果。
- SameSite Cookie 属性：设置 Cookie 时添加 SameSite=Strict 或 SameSite=Lax，可防止浏览器在跨站请求中自动发送 Cookie。Lax 模式允许安全的 GET 请求，适合大多数场景。
- 双重提交 Cookie：将 CSRF token 同时写入 Cookie 和请求参数/头中，服务器比对两者是否一致。无需服务端存储，适合分布式系统。
开发中需要注意什么？
现代框架如 Django、Spring Security 等默认提供 CSRF 防护机制，但开发者仍需注意：
- 确保防护机制在所有敏感操作（尤其是 POST、PUT、DELETE）上启用。
- API 接口若使用 Token 认证（如 JWT），应避免自动携带凭证（如不使用 Cookie 存储 token），并配合自定义头（如 X-CSRF-Token）来防范。
- 静态资源页面（如管理后台）必须启用完整防护，不能因“只读”就忽略。
基本上就这些。关键在于识别哪些操作需要保护，并正确实施 token 或 SameSite 等机制。不复杂但容易忽略。
