<p><!--META { "title": "CSPによるXSS攻撃緩和策", "primary_category": "Webセキュリティ", "secondary_categories": ["XSS","CSP"], "tags": ["Content-Security-Policy", "XSS", "Webセキュリティ", "nonce", "strict-dynamic", "HTTPヘッダー"], "summary": "CSPはXSS攻撃緩和に有効なHTTPヘッダーです。本記事ではその仕組み、効果的な設定、運用上の注意点を解説します。", "mermaid": true, "verify_level": "L0", "tweet_hint": {"text":"CSPによるXSS攻撃緩和策について解説！ 効果的な設定方法、<code>nonce</code>や<code>strict-dynamic</code>の活用、運用時の注意点まで、セキュリティエンジニアが押さえるべきポイントを網羅。 #Webセキュリティ #CSP #XSS","hashtags":["#Webセキュリティ","#CSP"]}, "link_hints": ["https://developer.mozilla.org/ja/docs/Web/HTTP/CSP","https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html"] } --> 本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト（未検証）</strong>です。</p> <h1 class="wp-block-heading">CSPによるXSS攻撃緩和策</h1> <p>ウェブアプリケーションにおけるクロスサイトスクリプティング（XSS）攻撃は、長年にわたり主要なセキュリティ脅威の一つであり続けています。Content Security Policy（CSP）は、このXSS攻撃を効果的に緩和するための強力なHTTPレスポンスヘッダーです。本記事では、セキュリティエンジニアの実務家向けに、CSPの仕組み、推奨される設定、および運用上の注意点について解説します。</p> <h2 class="wp-block-heading">脅威モデル：クロスサイトスクリプティング（XSS）</h2> <p>XSSは、攻撃者が悪意のあるスクリプトをウェブページに挿入し、そのスクリプトが他のユーザーのブラウザで実行されることによって発生する脆弱性です。成功した場合、攻撃者はユーザーのセッションハイジャック、Cookieの盗難、個人情報の窃取、ウェブサイトの改ざんなどを実行できます。XSS攻撃は主に以下の3種類に分類されます [2]。</p> <ul class="wp-block-list"> <li><p><strong>Reflected XSS（反射型XSS）</strong>: 攻撃者の入力がWebアプリケーションによって即座に、かつ検証されずにHTMLレスポンスに反映されることで発生します。フィッシングメールなどを通じて悪意のあるURLをクリックさせることで実行されます。</p></li> <li><p><strong>Stored XSS（格納型XSS）</strong>: 攻撃者の入力がWebアプリケーションのデータベースなどに保存され、他のユーザーがその保存されたコンテンツを閲覧する際に悪意のあるスクリプトが実行されることで発生します。掲示板の投稿やコメント欄などが典型的な標的です。</p></li> <li><p><strong>DOM-based XSS（DOMベース型XSS）</strong>: WebページのDOM（Document Object Model）を操作するクライアントサイドのスクリプトに脆弱性があり、ユーザーの入力が適切に処理されずにDOMに反映されることで発生します。サーバーサイドの処理を経由せず、ブラウザのみで完結する点が特徴です。</p></li> </ul> <h2 class="wp-block-heading">攻撃シナリオとCSPの役割</h2> <p>CSPが導入されていないウェブアプリケーションでは、以下のようなシナリオでXSS攻撃が成功する可能性があります。</p> <ol class="wp-block-list"> <li><p><strong>攻撃者によるスクリプト挿入</strong>: 攻撃者は、入力フォームやURLパラメータなどを通じて、<code><script>alert('XSS');</script></code>のような悪意のあるJavaScriptコードをアプリケーションに挿入します。</p></li> <li><p><strong>サーバーによる脆弱なレスポンス</strong>: アプリケーションは、ユーザーからの入力値を適切にサニタイズ（無害化）せずに、そのままHTMLレスポンスに含めてブラウザに送信します。</p></li> <li><p><strong>ブラウザでのスクリプト実行</strong>: ユーザーのブラウザは、受け取ったHTMLを解析し、含まれる悪意のあるスクリプトを信頼されたコンテンツとして実行してしまいます。</p></li> </ol> <p>CSPは、HTTPレスポンスヘッダーを通じて、ブラウザがどのオリジンからどのタイプのリソースを読み込むことを許可するかを厳密に定義することで、このスクリプト実行フェーズに介入します。例えば、CSPが「このページは自身のドメインからのみスクリプトを読み込む」と指示していれば、外部ドメインから挿入されたスクリプトはブロックされます。</p> <p>CSPのバイパス手法も存在しますが、これらは主にCSPポリシーが不適切に設定されている場合に発生します [6]。例えば、<code>'unsafe-inline'</code>や<code>'unsafe-eval'</code>ディレクティブをポリシーに含めると、インラインスクリプトや<code>eval()</code>関数によるコード実行が許可され、XSS攻撃に利用される可能性があります。</p> <h2 class="wp-block-heading">検出と緩和策：効果的なCSPの導入</h2> <p>CSPは、ウェブサーバーがHTTPレスポンスヘッダーとして<code>Content-Security-Policy</code>を送信することで機能します。このポリシーは、<code>default-src</code>、<code>script-src</code>、<code>style-src</code>などのディレクティブで構成され、それぞれ特定のリソースタイプ（スクリプト、スタイルシートなど）に対して許可されるオリジンを指定します [1]。</p> <h3 class="wp-block-heading">基本的なディレクティブと危険な設定</h3> <p>以下のディレクティブは、CSPポリシーの基本的な構成要素です [1]。</p> <ul class="wp-block-list"> <li><p><strong><code>default-src</code></strong>: 他の特定のディレクティブが指定されていない場合のフォールバックポリシー。</p></li> <li><p><strong><code>script-src</code></strong>: JavaScriptソースの許可オリジン。</p></li> <li><p><strong><code>style-src</code></strong>: CSSスタイルシートの許可オリジン。</p></li> <li><p><strong><code>img-src</code></strong>: 画像の許可オリジン。</p></li> <li><p><strong><code>connect-src</code></strong>: <code>XMLHttpRequest</code>、<code>WebSocket</code>などのネットワーク接続の許可オリジン。</p></li> <li><p><strong><code>object-src</code></strong>: <code><object></code>、<code><embed></code>、<code><applet></code>タグの許可オリジン。</p></li> <li><p><strong><code>base-uri</code></strong>: <code><base></code>タグで指定できるURLを制限。</p></li> </ul> <p><strong>避けるべきディレクティブ</strong>: <code>'unsafe-inline'</code>はインラインスクリプトやスタイルを許可し、<code>'unsafe-eval'</code>は<code>eval()</code>のような文字列からコードを生成するメソッドを許可します。これらはXSS攻撃の経路となり得るため、セキュリティレベルを著しく低下させます [4]。</p> <h3 class="wp-block-heading">推奨されるCSP設定：NonceとStrict-Dynamic</h3> <p>最新のCSP推奨事項では、<code>nonce</code>（ナンバー・オン・スロープ）や<code>hash</code>、そして<code>strict-dynamic</code>を活用することで、より堅牢なポリシーを構築します [5]。</p> <ul class="wp-block-list"> <li><p><strong>Nonce（ノンス）</strong>: リクエストごとに一意のランダムな文字列（ノンス）を生成し、それを<code>script-src</code>ディレクティブと、許可したい<code><script></code>タグの<code>nonce</code>属性の両方に含めます。これにより、ノンスを知らない攻撃者が挿入したスクリプトは実行されません。</p></li> <li><p><strong>Hash（ハッシュ）</strong>: 許可したいインラインスクリプトの内容のハッシュ値をCSPポリシーに含めます。コードが変更されるとハッシュ値も変わるため、改ざんを検出できます。</p></li> <li><p><strong><code>'strict-dynamic'</code></strong>: ノンスまたはハッシュで許可されたスクリプトが、さらに信頼できるスクリプトを動的にロードすることを許可します。これにより、大規模なアプリケーションで多くのスクリプトタグにノンスを付与する手間を省きつつ、セキュリティを維持できます [5]。</p></li> </ul> <h4 class="wp-block-heading">安全な代替策のコード例</h4> <p><strong>誤用例（推奨されないCSP）</strong>: <code>unsafe-inline</code>や<code>unsafe-eval</code>はXSS脆弱性の温床となります。</p> <div class="codehilite"> <pre data-enlighter-language="generic">Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; object-src 'none'; </pre> </div> <p>このポリシーは、自身のオリジンからのスクリプトを許可しつつも、インラインスクリプトや<code>eval()</code>の使用も許可しているため、反射型XSSや格納型XSSに対して脆弱な状態です。攻撃者がどこか一点でもユーザー入力がHTMLに直接出力される箇所を見つければ、悪意のあるインラインスクリプトを実行できてしまいます。</p> <p><strong>安全な代替（推奨されるCSP）</strong>: ノンスと<code>strict-dynamic</code>を組み合わせたポリシーは、最も強力なXSS緩和策の一つです。</p> <div class="codehilite"> <pre data-enlighter-language="generic">Content-Security-Policy: script-src 'nonce-{RANDOM_NONCE}' 'strict-dynamic'; object-src 'none'; base-uri 'self'; report-uri /csp-report-endpoint; </pre> </div> <p>このポリシーでは、<code>script-src</code>に指定された<code>'nonce-{RANDOM_NONCE}'</code>と<code>'strict-dynamic'</code>がポイントです。<code>{RANDOM_NONCE}</code>はサーバーがリクエストごとに生成し、HTMLレスポンス内の<code><script></code>タグの<code>nonce</code>属性にも設定します。これにより、ノンスを持つスクリプトのみが実行され、さらにそれらのスクリプトが動的に他のスクリプトをロードすることも許可されるため、アプリケーションの機能性を損なわずにXSS攻撃を防ぎます。<code>object-src 'none'</code>はプラグイン（Flashなど）による脆弱性を排除し、<code>base-uri 'self'</code>は<code><base></code>タグの悪用を防ぎます。<code>report-uri</code>は違反レポートの送信先です。</p> <h4 class="wp-block-heading">ノンスの生成例（Python）</h4> <p>ノンスは予測不可能な値である必要があります。暗号学的に安全な乱数ジェネレーターを使用して、リクエストごとに新しいノンスを生成します。</p> <div class="codehilite"> <pre data-enlighter-language="generic">import secrets import base64 def generate_csp_nonce(length_bytes=16) -> str: """ Content Security Policy (CSP) nonceを生成する関数。 長さlength_bytes（デフォルト16バイト）のランダムなバイト列を生成し、 Base64 URL-safeでエンコードする。これにより、攻撃者が予測しにくい 一意のnonceが生成される。 入力: length_bytes (int): 生成するバイト列の長さ。デフォルトは16。 出力: str: Base64 URL-safeでエンコードされたnonce文字列。 前提: secretsモジュールが利用可能であること。 計算量: O(1) (固定長の乱数生成とエンコード) メモリ条件: O(1) """ nonce_bytes = secrets.token_bytes(length_bytes) # 例: 16バイトの乱数を生成 # Base64 URL-safeエンコードし、ASCII文字列としてデコード nonce_base64 = base64.urlsafe_b64encode(nonce_bytes).decode('ascii') return nonce_base64.rstrip('=') # Base64URLセーフパディングを除去 # 使用例 (Webフレームワーク内でリクエストごとに実行) # current_nonce = generate_csp_nonce() # HTTPレスポンスヘッダー: "Content-Security-Policy: script-src 'nonce-{current_nonce}' 'strict-dynamic';" # HTMLのスクリプトタグ: <script nonce="{current_nonce}">...</script> </pre> </div> <h3 class="wp-block-heading">XSS攻撃チェーンとCSPによる介入</h3> <div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid"> flowchart TD A["攻撃者"] --> B{"悪意ある入力/スクリプト挿入"}; B --|SQLi/XSS経由| --> C["Webアプリケーション"]; C --|データ保存 (Stored XSS)| --> D["データベース"]; D --|出力時| --> C; C --|脆弱なレスポンス生成| --> E["ユーザーのブラウザ"]; E --|CSPなしの場合| --> F["悪意あるスクリプト実行"]; F --|セッションハイジャック/情報漏洩など| --> A; E --|CSP適用| --> G{"CSPポリシー評価"}; G --|許可されたリソースのみ| --> H["正当なスクリプト実行"]; G --|違反を検出| --> I["悪意あるスクリプトブロック"]; I --|レポート送信 (Report-URI)| --> J["CSPレポートエンドポイント"]; J --> K["セキュリティ監視/分析"]; </pre></div> <p>上記の図は、XSS攻撃の流れとCSPがどのように介入して攻撃を緩和するかを示しています。攻撃者が挿入したスクリプトがアプリケーションの脆弱性を経由してユーザーのブラウザに到達しても、CSPが適用されていれば、ポリシーに違反するスクリプトは実行がブロックされ、攻撃が水際で阻止されます。</p> <h2 class="wp-block-heading">運用対策と現場の落とし穴</h2> <p>CSPは強力なツールですが、その導入と運用には注意が必要です。</p> <h3 class="wp-block-heading">鍵/秘匿情報の取り扱い</h3> <p>CSPにおいて「鍵/秘匿情報」とは、主にノンスの生成に用いられるランダムな値そのものです。ノンスはリクエストごとに一意である必要があり、予測不可能な値でなければなりません。これを実現するために、OSが提供する暗号学的に安全な乱数ジェネレーター（Pythonの<code>secrets</code>モジュールなど）を使用することが不可欠です。</p> <ul class="wp-block-list"> <li><p><strong>ローテーション</strong>: ノンスはリクエストごとに異なるため、厳密な意味でのローテーションは不要です。各リクエストで新しい一意のノンスが生成され、使い捨てされます。</p></li> <li><p><strong>最小権限</strong>: CSPポリシー自体は、許可するリソースのオリジンを最小限に絞ることで「最小権限の原則」を体現します。</p></li> <li><p><strong>監査</strong>: <code>report-uri</code>または<code>report-to</code>ディレクティブを設定することで、CSP違反が発生した際にブラウザからレポートを受け取ることができます。これにより、潜在的なXSS攻撃の試みや、ポリシーの誤設定による正当なリソースのブロックを検知し、監査することが可能になります。これらのレポートを集約・分析する仕組み（例：Report-URI.comなどのサービスや自社構築のエンドポイント）を用意することが重要です。</p></li> </ul> <h3 class="wp-block-heading">導入時のフェーズとレポートモード</h3> <p>CSPをいきなり強制モードで導入すると、正当なスクリプトやリソースがブロックされ、アプリケーションの機能が停止する可能性があります。そのため、以下のフェーズでの導入が推奨されます [6]。</p> <ol class="wp-block-list"> <li><p><strong><code>Content-Security-Policy-Report-Only</code>モードでのテスト</strong>: このヘッダーを使用すると、ポリシー違反が発生してもスクリプトの実行はブロックされず、レポートのみが指定されたエンドポイントに送信されます。これにより、アプリケーションへの影響なしにポリシーの有効性を検証し、必要な調整を行うことができます。</p> <div class="codehilite"> <pre data-enlighter-language="generic">Content-Security-Policy-Report-Only: script-src 'nonce-{RANDOM_NONCE}' 'strict-dynamic'; object-src 'none'; report-uri /csp-report-endpoint; </pre> </div></li> <li><p><strong>ポリシーの調整と移行</strong>: レポートを分析し、アプリケーションが必要とするすべてのリソースが許可されるようにポリシーを調整します。十分なテスト期間を経て問題がないことを確認したら、<code>Content-Security-Policy</code>ヘッダーに移行します。</p></li> </ol> <h3 class="wp-block-heading">現場の落とし穴</h3> <ul class="wp-block-list"> <li><p><strong>ポリシーの複雑化とメンテナンス負荷</strong>: 多様な外部サービスを利用しているアプリケーションでは、ポリシーが非常に複雑になりがちです。ポリシーが長すぎると、HTTPヘッダーのサイズ制限に抵触したり、可読性が低下してメンテナンスが困難になる可能性があります。定期的な見直しと整理が必要です。</p></li> <li><p><strong>誤検知と検出遅延</strong>: <code>Report-Only</code>モードでのテストが不十分だと、本番環境移行後に正当な機能がブロックされる「誤検知」が発生し、可用性に影響を与えます。また、報告された違反レポートの分析が遅れると、攻撃の兆候を見逃す「検出遅延」につながります。</p></li> <li><p><strong>不完全なXSS緩和</strong>: CSPはXSS緩和の強力な手段ですが、万能ではありません。DOM-based XSSの一部は、CSPだけでは完全に防ぎきれない場合があります。また、JSONPエンドポイントの悪用や、CSPヘッダー自体に注入される反射型XSSなど、バイパス手法も存在します。サーバーサイドでの厳格な入力検証、出力エンコーディング、セキュアなJavaScriptコーディング（例：信頼できない文字列からのHTML生成を避ける）を組み合わせることが不可欠です。</p></li> <li><p><strong>WAF/IDSとの連携</strong>: CSPはクライアントサイドでの保護を提供しますが、Web Application Firewall (WAF) や Intrusion Detection System (IDS) はサーバーサイドでの保護を提供します。これらを組み合わせることで、多層防御を実現し、より広範な攻撃に対応できます。</p></li> </ul> <h2 class="wp-block-heading">まとめ</h2> <p>Content Security Policy (CSP) は、XSS攻撃を緩和するための非常に効果的なメカニズムです。特に<code>nonce</code>と<code>strict-dynamic</code>を組み合わせた現代的なアプローチは、アプリケーションの機能性を維持しつつ、高いセキュリティレベルを提供します。</p> <p>しかし、CSPの導入と運用には、<code>Report-Only</code>モードでの慎重なテスト、継続的なポリシーの監視と更新、そして他のセキュリティ対策との組み合わせが不可欠です。開発者とセキュリティ担当者が連携し、最新のベストプラクティスに従うことで、ウェブアプリケーションをXSSの脅威から保護し、ユーザーに安全な体験を提供することができます。</p> <hr/> <p><strong>参照情報:</strong></p> <p>[1] Mozilla Contributors. “Content Security Policy (CSP)”. MDN Web Docs, 2024年5月28日更新. <a href="https://developer.mozilla.org/ja/docs/Web/HTTP/CSP">https://developer.mozilla.org/ja/docs/Web/HTTP/CSP</a></p> <p>[2] OWASP. “Cross-site Scripting (XSS)”. OWASP, 2023年9月23日更新. <a href="https://owasp.org/www-community/attacks/xss/">https://owasp.org/www-community/attacks/xss/</a></p> <p>[3] Mozilla Contributors. “CSP: script-src”. MDN Web Docs, 2024年5月28日更新. <a href="https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Content-Security-Policy/script-src">https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Content-Security-Policy/script-src</a></p> <p>[4] Google. “Mitigating XSS with CSP”. Google Developers, 2024年1月19日更新. <a href="https://developer.chrome.com/docs/lighthouse/best-practices/csp-xss/">https://developer.chrome.com/docs/lighthouse/best-practices/csp-xss/</a></p> <p>[5] Google. “CSP strict-dynamic”. Google Developers, 2024年1月19日更新. <a href="https://developer.chrome.com/docs/web/fundamentals/security/csp/#strict-dynamic">https://developer.chrome.com/docs/web/fundamentals/security/csp/#strict-dynamic</a></p> <p>[6] OWASP. “Content Security Policy Cheat Sheet”. OWASP Cheat Sheet Series, 2024年1月2日更新. <a href="https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html">https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html</a></p>

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; object-src 'none';

Content-Security-Policy: script-src 'nonce-{RANDOM_NONCE}' 'strict-dynamic'; object-src 'none'; base-uri 'self'; report-uri /csp-report-endpoint;

import secrets
import base64

def generate_csp_nonce(length_bytes=16) -> str:
    """
    Content Security Policy (CSP) nonceを生成する関数。
    長さlength_bytes（デフォルト16バイト）のランダムなバイト列を生成し、
    Base64 URL-safeでエンコードする。これにより、攻撃者が予測しにくい
    一意のnonceが生成される。

    入力:
        length_bytes (int): 生成するバイト列の長さ。デフォルトは16。
    出力:
        str: Base64 URL-safeでエンコードされたnonce文字列。

    前提:
        secretsモジュールが利用可能であること。
    計算量:
        O(1) (固定長の乱数生成とエンコード)
    メモリ条件:
        O(1)
    """
    nonce_bytes = secrets.token_bytes(length_bytes) # 例: 16バイトの乱数を生成

    # Base64 URL-safeエンコードし、ASCII文字列としてデコード

    nonce_base64 = base64.urlsafe_b64encode(nonce_bytes).decode('ascii')
    return nonce_base64.rstrip('=') # Base64URLセーフパディングを除去

# 使用例 (Webフレームワーク内でリクエストごとに実行)


# current_nonce = generate_csp_nonce()


# HTTPレスポンスヘッダー: "Content-Security-Policy: script-src 'nonce-{current_nonce}' 'strict-dynamic';"


# HTMLのスクリプトタグ: <script nonce="{current_nonce}">...</script>

flowchart TD
    A["攻撃者"] --> B{"悪意ある入力/スクリプト挿入"};
    B --|SQLi/XSS経由| --> C["Webアプリケーション"];
    C --|データ保存 (Stored XSS)| --> D["データベース"];
    D --|出力時| --> C;
    C --|脆弱なレスポンス生成| --> E["ユーザーのブラウザ"];
    E --|CSPなしの場合| --> F["悪意あるスクリプト実行"];
    F --|セッションハイジャック/情報漏洩など| --> A;
    E --|CSP適用| --> G{"CSPポリシー評価"};
    G --|許可されたリソースのみ| --> H["正当なスクリプト実行"];
    G --|違反を検出| --> I["悪意あるスクリプトブロック"];
    I --|レポート送信 (Report-URI)| --> J["CSPレポートエンドポイント"];
    J --> K["セキュリティ監視/分析"];