如何防范跨站请求伪造？

本文目录导读：

1. 使用CSRF令牌（最主流的方法）
2. 验证请求的来源
3. 使用SameSite Cookie属性（现代浏览器的天然防御）
4. 双重提交Cookie
5. 关键操作增加二次确认
6. 避免使用GET请求执行状态更改
7. 使用自定义请求头
8. 防止JSON/API接口的CSRF
9. 综合防护建议
10. 补充：CSRF本质与常见误区

防范跨站请求伪造（CSRF）的核心原则是确保请求的来源合法性和用户意图的明确性,以下是具体且有效的防护措施：

使用CSRF令牌（最主流的方法）

• 原理：服务器生成一个唯一、随机的令牌，嵌入到表单或请求头中，提交请求时,服务器验证令牌是否匹配。
• 实施：对于所有更改状态的操作（如POST、PUT、DELETE），必须携带该令牌，令牌应绑定用户会话，且每次会话更新一次（或每次请求刷新）。
• 示例：<input type="hidden" name="_csrf_token" value="随机值">。
• 注意：令牌不能通过Cookie传递（否则会被自动携带）,应通过表单字段或自定义请求头传递。

验证请求的来源

• 检查Origin或Referer头：
  • 服务器端验证请求头中的 Origin（更可靠）或 Referer（可能缺失或伪造，但仍有作用）。
  • 白名单机制：只允许来自可信域名的请求。
• 注意事项：部分浏览器或隐私设置可能不发送这些头（如HTTPS→HTTP）,因此应结合其他方法使用。

使用SameSite Cookie属性（现代浏览器的天然防御）

• 设置：在Cookie中增加 SameSite 属性，可设为 Strict 或 Lax。
  • Strict：完全禁止跨站携带Cookie（适用于敏感操作）。
  • Lax：允许导航到目标网址的GET请求携带Cookie（适用于普通链接）。
• 效果：浏览器自动阻止跨域请求携带Cookie,使CSRF攻击失效。
• 注意：需要用户浏览器支持（现代主流浏览器均已支持）,且对旧版浏览器需保留其他防御。

双重提交Cookie

• 原理：服务器要求每个请求同时包含一个Cookie中的随机值和一个请求头（或请求体）中的相同值，由于攻击者无法读取目标站点的Cookie,无法构造正确的双重提交。
• 适用场景：适合无状态API或无法使用令牌的简单场景。

关键操作增加二次确认

• 方式：对高危操作（如转账、删除账号）要求用户输入密码、验证码（如图形验证码、短信验证码）或进行生物识别。
• 效果：即使请求被伪造,攻击者也无法通过验证。

避免使用GET请求执行状态更改

• 原则：遵循HTTP动词语义——GET只用于读取，POST/PUT/DELETE用于写入，这能减少CSRF利用GET触发的风险（例如通过图片标签的src属性发起GET请求）。

使用自定义请求头

• 原理：在AJAX或API请求中添加自定义头（如 X-Requested-With: XMLHttpRequest），由于跨域请求无法自动携带自定义头（除非预检请求允许）,可有效过滤简单CSRF。
• 适用场景：前后端分离项目,配合CORS策略使用。

防止JSON/API接口的CSRF

• 方法：对于RESTful API，要求所有写操作必须携带 application/json 的Content-Type，并验证令牌或头，简单表单提交（如application/x-www-form-urlencoded）本身容易利用,需重点保护。

综合防护建议

• 多层级结合：不要依赖单一方法，SameSite Cookie + CSRF令牌 + 来源检查”可大幅降低风险。
• 框架集成：现代Web框架（如Spring Security、Django、Express.js的csurf模块）已内置CSRF保护,建议直接使用。
• 定期测试：使用安全扫描工具或手动测试（如通过Burp Suite构造跨站请求）验证防护有效性。

补充：CSRF本质与常见误区

• 关键点：CSRF不窃取Cookie，而是利用用户已认证的会话发起恶意请求，因此不能仅靠HTTPS或加密Cookie来防御。
• 误伤排除：避免使用Referer作为唯一验证（某些合法跳转可能不携带），以及注意Token的泄漏（如果被XSS获取，则防御失效——所以必须同时防范XSS）。

通过上述措施的组合，可以显著降低CSRF攻击成功概率，对于高安全需求场景（如金融、医疗），建议使用Token + SameSite + 二次验证的三重保护。