【実務・中級編】クロスサイトスクリプティング（XSS）とCSRFの複合攻撃 – アプリケーションセキュリティ & 安全な開発防御ガイド

脆弱性の「連鎖」を断て：XSSからCSRFを紐解く、実戦的セキュリティ戦略

現場で戦うエンジニア諸君、お疲れ様。今日もどこかのサーバーで脆弱性が突かれ、深夜の呼び出しに怯える日々を過ごしていないか？

多くの開発者は「XSS対策はサニタイズ」「CSRF対策はトークン」と教科書通りに理解している。だが、真のプロフェッショナルは、「脆弱性は単体で死ぬのではなく、チェーン（連鎖）で組織を殺す」という事実を知っている。

今日は、XSSでAnti-CSRFトークンを盗み出し、CSRFを成立させる「攻撃チェーン」のメカニズムを解剖し、二度と突破させないための防壁構築法を叩き込む。

—

1. なぜ「複合攻撃」が最強の脅威なのか

通常、CSRF対策として発行されるAnti-CSRFトークンは、攻撃者が推測できないランダムな文字列だ。しかし、WebアプリケーションにXSS（クロスサイトスクリプティング）の穴があれば、話は別だ。

攻撃のロジック（PoCのイメージ）

1. XSS発動: 攻撃者は標的のブラウザ上でスクリプトを実行させる。
2. DOMの窃盗: スクリプトがDOMを走査し、の値を読み取る。
3. リクエスト偽装: 盗み出した有効なトークンを付与して、バックエンドへPOSTリクエストを送信する。
4. 陥落: サーバー側は「正しいトークン」が送られてきたと判断し、攻撃者の意図する操作（パスワード変更や決済）を許可する。

「トークンさえあればCSRFは防げる」という神話は、XSSという土台が崩れた瞬間に霧散する。これが、セキュリティを単一レイヤーで考えてはいけない理由だ。

—

2. 対策の核心：多層防御の実装

対策は大きく分けて「XSSを潰す」ことと「トークンの漏洩を防ぐ」ことの二段構えだ。

A. トークンの漏洩を防ぐ設計（SameSite Cookie）

まずは、トークンがJavaScriptから読み取れないようにすることだ。PHPなどでのセッション管理には、必ず SameSite 属性を指定せよ。

// PHPでのセッション設定例 (php.ini または session_set_cookie_params)
session_set_cookie_params([
‘lifetime’ => 0,
‘path’ => ‘/’,
‘domain’ => ‘yourdomain.com’,
‘secure’ => true, // HTTPS必須
‘httponly’ => true, // JavaScriptからのアクセス禁止（重要！）
‘samesite’ => ‘Strict’ // CSRF対策の強力な味方
]);
session_start();

HttpOnly を有効にすることで、万が一XSSが発動しても、攻撃者は document.cookie からセッションIDを盗むことができなくなる。

B. 実装コード：堅牢なCSRF対策トークン（Python/Flask例）

トークンをDOMに埋め込む際も、攻撃者が拾いにくい工夫が必要だ。以下は、安全なトークン生成の基本パターンだ。

import secrets
from flask import Flask, session, request, abort

app = Flask(__name__)

トークンの生成と検証（実務的な最小構成）
def generate_csrf_token():
if ‘_csrf_token’ not in session:
session[‘_csrf_token’] = secrets.token_hex(32)
return session[‘_csrf_token’]

@app.before_request
def csrf_protect():
if request.method == “POST”:
token = session.get(‘_csrf_token’, None)
# フォームのhiddenフィールドではなく、カスタムヘッダーで送るのが現代流
if not token or token != request.headers.get(‘X-CSRF-Token’):
abort(403) # トークン不一致なら即座に拒否

テンプレートに渡す際は、DOMに直書きせずメタタグを活用するのが定石

—

3. インフラレベルでの追い込み：CSP（Content Security Policy）

コードレベルの対策は完璧でも、フレームワークのバグやサードパーティ製ライブラリの脆弱性でXSSが起きる可能性はゼロにはできない。そこで最後に頼るべきは CSP（コンテンツセキュリティポリシー） だ。

NginxやWebサーバーの設定で、インラインスクリプトの実行を全面的に禁止せよ。

Nginx設定例: CSPヘッダーの付与
add_header Content-Security-Policy “default-src ‘self’; script-src ‘self’; object-src ‘none’; frame-ancestors ‘none’;” always;

script-src 'self': 外部からの怪しいJS読み込みを禁止する。
object-src 'none': Flashなどの古い脆弱なプラグインを無効化する。
frame-ancestors 'none': クリックジャッキング攻撃も併せて防御する。

—

4. チーフからの助言：脆弱性は「消す」のではなく「封じ込める」

最後に一つだけ伝えておく。完璧なコードを書こうと躍起になるな。人間が書くコードにバグはつきものだ。

重要なのは、「もしXSSが起きたら？」という最悪のケースを想定した設計だ。

トークンはHTMLの input フィールドではなく、HttpOnly なクッキーやカスタムヘッダーで扱う。
CSPでインラインスクリプトを一切許さない。
機密性の高い操作には、再認証（パスワード再入力）を強制する。

セキュリティは、攻撃者が「コストに見合わない」と判断して諦めるラインまで引き上げれば勝ちだ。今日教えたコードをそのままコピペするだけでなく、君たちのプロダクトにどう「多層防御」を組み込めるか、明日から設計書を読み返してみてくれ。

現場からは以上だ。また次のインシデント（の予防）で会おう。