CSRF（跨站请求伪造）详解

CSRF（Cross-Site Request Forgery，跨站请求伪造）是一种利用用户已登录身份，在用户不知情下执行非本意操作的攻击方式。常被戏称为"沉睡的间谍"或"骑在用户会话上的攻击"。

一、攻击原理（三个关键要素）

CSRF攻击能够成功，需要同时满足以下三个条件：

1. 用户已登录目标网站：用户浏览器中保存了目标网站的有效认证凭证（如Cookie、Session ID）。
2. 目标网站未校验请求来源：服务器仅依赖Cookie判断身份，不验证请求是否由用户本人真实发起。
3. 攻击者能构造恶意请求：攻击者可以诱导用户访问一个恶意页面或点击恶意链接，该页面会自动向目标网站发起请求。

🔥 经典攻击流程示例

假设某银行的转账接口是：

POST /transfer
参数：toAccount=目标账户&amount=金额

正常流程：用户在银行网站填写表单 → 点击"转账" → 浏览器带上用户的Cookie发送请求。

CSRF攻击流程：

1. 用户登录银行网站（获得合法Cookie）。
2. 攻击者构造一个恶意页面，包含一个隐藏表单或图片链接：

<!-- 恶意网站 evil.com 上的代码 -->
<img src="https://bank.com/transfer?toAccount=attacker&amount=10000" style="display:none">

3. 用户访问恶意网站（可能是通过钓鱼邮件、垃圾广告等诱导）。
4. 浏览器自动加载图片 → 自动携带用户在 bank.com 的Cookie → 发送转账请求。
5. 银行服务器校验Cookie通过 → 误以为是用户本人操作 → 执行转账。

二、CSRF攻击的主要体现形式

实际案例

• 修改密码：用户访问恶意页面，自动发送修改密码请求，把密码改成攻击者指定的。
• 发表言论：在用户不知情下，自动发送带恶意链接的微博/论坛帖子。
• 购物下单：自动把商品加入购物车并下单，寄送到攻击者地址。

三、CSRF vs XSS（关键区别）

一句话总结：

• XSS：攻击代码在目标网站上运行，窃取用户信息或控制页面。
• CSRF：攻击代码在第三方网站上运行，利用用户已登录的身份执行操作。

四、防御CSRF的核心方案（实战建议）

✅ 1. 使用CSRF Token（最经典有效）

服务器生成一个随机的、不可预测的Token，嵌入到表单或请求头中，服务器验证必须携带正确的Token。

<!-- 服务器返回的页面包含Token -->
<form action="/transfer" method="POST">
    <input type="hidden" name="csrf_token" value="random_token_abc123">
    转账金额: <input type="text" name="amount">
</form>

工作流程：

1. 用户请求表单页面 → 服务器生成Token存入Session并返回给表单。
2. 用户提交表单 → 必须携带该Token。
3. 服务器验证Token是否匹配 → 不匹配则拒绝请求。

优点：攻击者无法获取该Token（因为同源策略限制，恶意网站无法读取目标网站的页面源码）。
缺点：需要所有修改状态的操作都嵌入Token，实现成本稍高。

✅ 2. SameSite Cookie属性（现代浏览器推荐）

设置Cookie的SameSite属性，限制第三方域名发起的请求携带Cookie。

Set-Cookie: session_id=xyz123; SameSite=Lax; Secure; HttpOnly

SameSite取值：

• Strict：任何跨站请求都不带Cookie（最安全，但可能影响正常的外链跳转）。
• Lax：顶级导航（如点击链接）带Cookie，但POST表单、iframe、img等不带（推荐）。
• None：跨站请求也带Cookie，但必须同时设置Secure（仅HTTPS）。

优点：无需修改后端代码，配置简单，兼容主流现代浏览器（除IE外）。
缺点：旧浏览器不支持（如IE 11）。

✅ 3. 验证Referer/Origin头

检查请求头中的Referer或Origin是否与当前站点域一致。

def is_valid_request(request):
    referer = request.headers.get('Referer')
    if not referer:
        return False
    return referer.startswith('https://yourdomain.com')

优点：实现简单，无需额外存储。
缺点：某些场景下Referer可能缺失（如HTTPS到HTTP、用户隐私设置），部分低版本浏览器可伪造。

✅ 4. 二次验证（高安全场景）

对于敏感操作（修改密码、转账、手机解绑等），要求用户重新输入密码/短信验证码/图形验证码。

举例：网银转账超过一定金额，必须输入短信验证码。

优点：彻底防御CSRF，即使Token泄露也无法绕过。
缺点：影响用户体验，仅适用于高敏感操作。

✅ 5. 使用自定义请求头（针对API）

要求所有API请求必须携带一个自定义Header（如X-Requested-With: XMLHttpRequest），因为跨域请求无法设置自定义Header（除非CORS明确允许）。

// 前端Ajax请求自动添加
fetch('/transfer', {
    headers: {
        'X-Requested-With': 'XMLHttpRequest'
    }
})

注意：这要求所有请求都是Ajax方式，传统表单提交不适用。

五、总结与最佳实践

推荐防御组合（分层防御，纵深保护）

1. 基础层：使用CSRF Token + SameSite=Lax Cookie（现代框架如Django、Spring、Rails均内置支持）。
2. 增强层：敏感操作加入二次验证（密码/验证码）。
3. 兜底层：验证Referer/Origin作为辅助检测。

常见误区

• ❌ 仅依赖POST请求就认为安全（攻击者同样可以伪造POST表单）。
• ❌ 使用验证码防御所有请求（体验差，不适合每个操作）。
• ❌ 认为SameSite能100%防御（旧浏览器不支持，且仅限制Cookie携带，无法防御已窃取到Token的场景）。

框架内置支持

• Django：CsrfViewMiddleware（默认开启）
• Spring Security：CsrfFilter（默认开启）
• Express (Node.js)：csurf 中间件
• Laravel (PHP)：VerifyCsrfToken 中间件

如果你需要某段具体的防御代码示例（比如用Python Flask或Java Spring实现CSRF Token），可以告诉我，我为你写一个可以直接运行的demo。