XSSを「踏み台」にするCSRF：防衛ラインを崩壊させる攻撃チェーンの解剖学
セキュリティの現場において、XSS（クロスサイトスクリプティング）とCSRF（クロスサイトリクエストフォージェリ）を別々の問題として扱う時代は終わった。現代の洗練された攻撃者は、これらを「点」ではなく「線」で捉える。
特に、ドメインの信頼関係を悪用し、Anti-CSRFトークンという「最後の砦」をXSSで掠め取る攻撃チェーンは、アーキテクトが最も恐れる悪夢の一つだ。本稿では、この複合攻撃のメカニズムを低レイヤの視点から解剖し、我々が実装すべき「真の防御アーキテクチャ」について議論する。
—
1. 攻撃チェーンのメカニズム：信頼の連鎖を断ち切るロジック
通常、CSRF対策として実装されるAnti-CSRFトークンは、サーバーサイドで生成され、セッションと紐付けられる。攻撃者がこれをバイパスするには、トークンの値を特定せねばならない。
ここでXSSが介入する。攻撃者が標的サイトにスクリプトを注入できれば、そのコンテキストは「正規ユーザーのブラウザ」そのものだ。
1. 偵察 (Reconnaissance): XSSを通じて、DOM上のHiddenフィールド、あるいはHTTPリクエストヘッダ（カスタムヘッダ等）からトークンを読み取る。
2. 権限奪取 (Exfiltration): 読み取ったトークンを攻撃者のC2サーバーへ送信。
3. 実行 (Execution): 攻撃者は盗み出したトークンを使い、正規ユーザーの権限でリクエストを捏造し、サーバーを欺く。
これは単なるWebアプリのバグではなく、「ブラウザの同一生成元ポリシー（SOP）の境界を、コンテキスト内部から突破される」という、アーキテクチャの根底を揺るがす事態だ。
—
2. 脆弱性の深層：ブラウザの制約と「隙」
この攻撃が成立する最大の要因は、JavaScriptが「正規のフロントエンド」として振る舞うことで、ブラウザがCSRF対策のチェックを「正当な要求」と誤認することにある。
特に危険なのは、「SPA（Single Page Application）におけるAPI認証設計の甘さ」だ。トークンを単なるDOM要素として配置し、かつXSS脆弱性を放置していれば、それは「強固な鍵を金庫に入れ、その金庫の鍵を玄関マットの下に置く」のと同じである。
防御の要：HTTP-Onlyから「Context-Aware」へ
対策の基本は「XSSの撲滅」だが、人間が書くコードにバグはつきものだ。だからこそ、防御層を多重化する。
A. SameSite Cookie属性の厳格化
SameSite=Strict をデフォルトに設定するのは最低条件だ。だが、これだけではサブドメインの乗っ取りによる影響を完全に防げない。
B. 二重送信クッキー（Double Submit Cookie）の限界と進化
トークンをクッキーだけでなく、HTTPリクエストヘッダとして送受信させる手法は有効だが、攻撃者がXSSでJavaScript経由でクッキーにアクセスできては意味がない。
ここで、「トークンをJSから読み取り不可能な場所に置く」という設計が求められる。
// 【対策例】サーバーサイドでのヘッダ制御による保護
// 現代的なWebアプリでは、CSRFトークンをJSからアクセスできないよう、
// HttpOnlyかつSecureなCookieに保持し、カスタムヘッダで照合する設計が理想的だ。
// CSP（Content Security Policy）でインラインスクリプトを禁止し、
// 攻撃者のスクリプト実行自体を封じる（防御の多重化）
// 例：Content-Security-Policy: default-src ‘self’; script-src ‘self’; object-src ‘none’;
—
3. 次世代の防衛設計：ガードレイルとしてのセキュリティアーキテクチャ
今後の脅威、特に生成AIを用いた高度なプロンプトインジェクションや、自動化された脆弱性探索に対抗するためには、アプリケーション開発のレイヤで以下の防御層を構築すべきだ。
1. 認証のトークン化から「証明」への移行
CSRFトークンのような「静的な値」に依存せず、「リクエストそのものを署名する」モデル（JWS/JWEの応用など）への移行を推奨する。リクエストのペイロード全体を署名対象とすることで、攻撃者がトークンを盗んでも、ペイロードの改ざんができなくなる。
2. 生成AIガードレイルの統合
もしあなたのアプリがLLMと連携しているなら、プロンプトインジェクション経由でXSSが誘発される可能性が高い。入力値のサニタイズだけでなく、「出力フィルタリング」を徹底し、LLMが生成したコンテンツがフロントエンドで実行されないよう、厳格なDOMサニタイズ（DOMPurify等）をパイプラインに組み込むこと。
3. トラスト・バウンダリの分離
APIゲートウェイ側で、Origin や Referer の厳格なバリデーションを行うのは当然だが、さらに一歩進んで、「ユーザーセッションのスコープを物理的に切り分ける」アーキテクチャを検討せよ。機密情報の取り扱いには、専用の認証サブシステムを介する設計が、大規模インフラにおける「最後の防衛線」となる。
—
結論：セキュリティは「仕様」ではなく「規律」
XSS経由のCSRFを許すということは、システムの設計思想そのものに甘えがあることを意味する。
「スクリプトが注入されても、CSRFが防げるか？」
「トークンが漏洩しても、リクエストの改ざんを防げるか？」
この問いを設計段階でクリアできないアーキテクチャは、いずれ必ず破綻する。ツールに頼らず、通信のプロトコル仕様と、ブラウザのメモリ・DOMの挙動を深く理解し、泥臭く「攻撃者がどう裏をかこうとするか」を先回りして防ぐこと。それこそが、我々エンジニアが持つべき唯一の信頼の証明だ。
常に最悪の事態を想定し、防御を多層化せよ。コードは嘘をつかない。君たちの設計の甘さが、そのまま脆弱性としてシステムに刻まれるのだから。
コメント