1. 使用 CSRF Token

这是最常见和最可靠的防御方法

工作原理：
1. 服务器在用户登录后，生成一个随机、唯一的 CSRF Token，并将其存储在会话中或某个安全的地方（如 sessionStorage）
2. 服务器将 Token 发送给客户端
3. 客户端在发起任何敏感操作的请求时，都必须将这个 Token 放在HTTP 请求头或 POST 请求体中
4. 服务器接收到请求后，会验证请求中的 Token 是否与服务器上存储的 Token 相匹配。如果不匹配，则拒绝请求
在 JSON 请求中的实践：客户端的 JavaScript 代码在发起 POST 请求时，将 Token 放在一个自定义的 HTTP 头中，例如 X-CSRF-TOKEN
```
fetch('https://your-api.com/transfer', {
  method: 'POST',
  body: JSON.stringify({ to: 'attacker', amount: 1000 }),
  headers: {
    'Content-Type': 'application/json',
    'X-CSRF-TOKEN': 'your-generated-token'
  }
});
```
防御原理：攻击者无法从 your-api.com 域获取有效的 CSRF Token。由于同源策略的限制，恶意网站的 JavaScript 无法读取你的 API 返回的 HTML 或 JSON 数据，因此无法获取 CSRF Token。此外，即使是简单请求，自定义的 HTTP 头也会触发预检请求，同样会被 CORS 机制拦截

2. 使用 SameSite Cookie

前面我们讨论过 SameSite 属性。在 JSON API 的场景中，SameSite=Lax 同样是有效的防御

工作原理：将你的会话 Cookie 的 SameSite 属性设置为 Lax 或 Strict。当攻击者从恶意网站发起 POST 请求时，浏览器不会携带这个会话 Cookie。服务器在验证请求时，因为没有会话信息，会直接拒绝请求
```
Set-Cookie: sessionid=xxxx; SameSite=Lax; Secure; HttpOnly
```
最佳实践：
- SameSite=Strict：提供了最强的防御，但可能影响用户体验
- SameSite=Lax：在大多数情况下提供了足够的保护，同时不影响用户从其他网站通过 GET 链接跳转到你的网站

3. 验证 Referer 或 Origin 头

这种方法是辅助性的，但可以提供额外的安全层

工作原理：服务器检查请求头中的 Referer 或 Origin 字段，验证请求的来源是否为你的合法域名
- Referer：表示发起请求的 URL
- Origin：表示请求的来源域，通常用于 CORS 预检请求中
局限性：
- Referer 字段可以被一些浏览器或代理软件修改或删除
- 这不是一个完全可靠的防御方法，应作为辅助手段而非主要策略

3.2 JSON 格式的 CSRF 如何防御

results matching ""