CSRF攻击防御使用Token还是Referer

本文目录导读：

1. 为什么推荐使用 Token？
2. 为什么不推荐单独依赖 Referer？
3. 实际中如何选择？
4. 最佳实践：组合防御
5. 总结对比表
6. 实际代码示例（伪代码）

在防御CSRF攻击时,优先推荐使用 CSRF Token，而不是单纯依赖 Referer。

简要结论：Token 是主流、标准、可靠的防御方式；Referer 仅能作为辅助或降级方案，不可单独依赖。

以下是两者的详细对比分析：

为什么推荐使用 Token？

• 安全性与唯一性：Token 是服务器生成的、与用户会话绑定的随机字符串，攻击者无法提前获知，每次提交请求时，服务器验证 Token 是否匹配，从根本上防止了第三方网站构造合法请求。
• 不受环境限制：Token 在浏览器中通过隐藏字段或自定义 HTTP 头传递，不依赖请求头信息。
• 标准实践：主流框架（如 Spring Security、Django、Express.js）都内置了 CSRF Token 支持，实现简单且经过安全验证。

为什么不推荐单独依赖 Referer？

• Referer 可被篡改或缺失：
  • 用户访问 HTTPS 页面后，再通过 HTTP 发起请求时，某些浏览器会不发送 Referer 头。
  • 部分浏览器插件或安全软件可能会移除 Referer 头。
  • 攻击者可以通过修改 <form> 的 enctype 或使用 Flash 等插件方式，在某些情况下伪造 Referer。
  • iframe、跨域请求、直接输入地址或书签访问也可能导致 Referer 为空。
• 绕过风险：虽然 Referer 可以用于同源检查，但一旦攻击者发现某个你信任的域名存在 XSS 漏洞，可以利用该域名发起 CSRF 攻击，Referer 检测会被绕过。
• 可靠性不足：Referer 是客户端携带的信息，不应该作为唯一的安全决策依据。

实际中如何选择？

最佳实践：组合防御

现代 Web 安全推荐深度防御：

1. 首选：CSRF Token（在表单中加入隐藏字段或通过 X-CSRF-Token 请求头发送）。
2. 辅助：SameSite Cookie 属性（设置为 Strict 或 Lax，能有效阻止第三方网站发起的跨站请求）。
3. 环境补充：Referer/Origin 头检查（作为第二层验证，拦截明显异常的请求）。
4. 重要操作：二次确认（如支付时要求输入密码或验证码）。

总结对比表

实际代码示例（伪代码）

Token 防御：

# 服务端生成 Token 并注入表单
<form method="POST" action="/transfer">
  <input type="hidden" name="csrf_token" value="{{ token }}">
  <input type="text" name="amount">
</form>
# 服务端接收时验证
if request.form['csrf_token'] != session['csrf_token']:
    raise "CSRF Token 无效"

Referer 辅助检查：

def check_referer(request):
    referer = request.headers.get('Referer', '')
    # 检查是否以合法域名开头（只能作为辅助，不能百分百依赖）
    if not referer.startswith('https://yourdomain.com/'):
        # 可以记录日志或要求用户二次验证，但不应直接拒绝所有流量
        pass

最终建议： 只要你的项目条件允许，请一定使用 CSRF Token，如果旧的代码或框架无法支持 Token 生成，再考虑使用 Referer 作为临时应急方案，同时尽快升级替换。