https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/timing-attacks/Recent content on XS-Leaks WikiHugo -- gohugo.ioja-jphttps://webapppentestguidelines.github.io/xs-leaks/docs/attacks/timing-attacks/clocks/Thu, 01 Oct 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/timing-attacks/clocks/クロックには、明示的なものと暗黙的なものの2種類があります。 明示的なクロックは、開発者が直接タイミングを測定するために使用されるもので、その機構はブラウザによって明示的に提供されます。 一方で、暗黙的なクロックは、特定のWebの機能を利用して作り出される想定外のもので、それを利用することで相対的な時間経過を測定できるものです。 明示的なクロック # performance.now API # performance.now() APIは、開発者がより高精度に時間を計測することを可能にします。 info XS-Leaksのいくつかのタイプを緩和するため、performance.now()の精度は、すべてのモダンブラウザでナノ秒からマイクロ秒の範囲に縮小されました。123 Reduce resolution of performance.now (Webkit). link ↩︎ Reduce precision of performance.now() to 20us (Gecko). link ↩︎ Reduce resolution of performance.now to prevent timing attacks (Blink). link ↩︎ Date API # [Date] APIは、タイミング測定に使用できる最も古いブラウザのAPIです。 これにより開発者は日付を取得したり、Date.now()を使ってUnixタイムスタンプを取得したりすることができます。 より新しいAPIが導入される前は、このAPIが攻撃に使われていました。1 暗黙的なクロック # SharedArrayBufferとWeb Workers # Web Workersの導入に伴い、スレッド間でデータを交換するための新しいメカニズムが作られました。2それらの機構の一つがSharedArrayBufferで、メインスレッドとワーカスレッドの間でメモリ共有を提供します。悪意のあるウェブサイトは、バッファ内の数値をインクリメントさせる無限ループを実効するワーカーをロードすることで、implicit クロックを作成することができます。この値は、メインスレッドからいつでもアクセスでき、何回インクリメントが行われたかを読み取ることができる。 info Spectreの公開に伴い、SharedArrayBufferはブラウザから削除されました。 その後、2020年に再導入され、このAPIを利用する際はドキュメントがセキュアコンテキスト内にあることが要求されるようになりました。 セキュアコンテキストは、アクセスすることを明示的にオプトインしていないクロスオリジンコンテンツは参照できないので、これはSharedArrayBufferがいくつかのXS-Leakにおいてはクロックとして使用できないことを意味します。 モダンブラウザでSharedArrayBufferを使用するには、アプリケーションは以下のヘッダを設定することで、明示的にCOOPやCOEPを有効にする必要があります。 Cross-Origin-Opener-Policy: same-origin Cross-Origin-Embedder-Policy: require-corp // WebWorker内部で実行する関数を定義する function worker_function() { self.onmessage = function (event) { const sharedBuffer = event.https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/timing-attacks/network-timing/Thu, 01 Oct 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/timing-attacks/network-timing/ネットワーク タイミングのサイドチャネルは、ウェブが誕生したときから存在していました。これらの攻撃は、ブラウザがperformance.now()のような高精度のタイマーを出荷し始めたときに、新しい注目を集め、時とともに異なるレベルの影響を持つようになりました。 タイミング測定値を得るために、攻撃者は暗黙的または明示的なクロックを使用する必要があります。これらのクロックは、XS-Leaksの目的では通常交換可能であり、精度と利用可能性が異なるだけです。簡単のために、この記事では、すべてのモダンブラウザに存在する明示的なクロックであるperformance.now()APIを使用することを想定しています。 このサイドチャネルにより、攻撃者はクロスサイトリクエストが完了するまでにかかった時間から情報を推測することができます。ネットワークのタイミング測定は、ユーザーの状態によって変化する可能性があり、通常は下記の要素に連動します。 リソースサイズ バックエンドでの計算時間 サブリソースの数とサイズ キャッシュの状態. tip クロックの種類については、クロックの記事で詳しく説明しています。 モダンなWebのタイミング攻撃 # performance.now()は、リクエストの実行にかかる時間を測定するために使用できます。 // クロックを開始します。 var start = performance.now() // fetchリクエストが完了するまでの時間を計測します。 fetch('https://example.org', { mode: 'no-cors', credentials: 'include' }).then(() => { // fetch終了した時点で時間差を計算します。 var time = performance.now() - start; console.log("The request took %d ms.", time); }); Onloadイベント # 同じような処理で、リソースを取得するのにかかる時間を測定するには、単に onload イベントを監視することで可能です。 // 時間が欲しいページを指すscript要素を作成します。 var script = document.createElement('script'); script.src = "https://example.org"; document.body.appendChild(script); // クロックを開始します。 var start = performance.now(); // スクリプトがロードされたら、リクエストが完了するまでの時間を計算します。 script.onload = () => { var time = performance.https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/timing-attacks/performance-api/Thu, 01 Oct 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/timing-attacks/performance-api/Performance API # Performance APIは、Resource Timing APIのデータによって強化されたパフォーマンス関連の情報へのアクセスを提供します。このAPIは、持続時間のようなネットワークリクエストの時間情報を提供しますが、サーバーから送られたTiming-Allow-Origin: *ヘッダーがある場合、転送サイズとドメイン検索時間も提供されます。 このデータには、 performance.getEntriesまたはperformance.getEntriesByNameを使ってアクセスすることができます。また、performance.now()の差分を使って実行時間を取得することもできますが、これはミリ秒しか提供しないため、Chromeのfetchでは精度が低い可能性があります。 ネットワークのduration # リクエストのNetwork durationを performance API から取得することができます。 以下のスニペットはリクエストを実行し、200ms後に performance オブジェクトから持続時間を取得します。 async function getNetworkDuration(url) { let href = new URL(url).href; // duration = 0 のリクエストがあるため、fetch()の代わりに画像を使用する。 let image = new Image().src = href; // performance.getEntriesByName()に追加されるリクエストを待ちます。 await new Promise(r => setTimeout(r, 200)); // 最後に追加された時間を取得する let res = performance.getEntriesByName(href).pop(); console.log("Request duration: " + res.duration); return res.duration } await getNetworkDuration('https://example.org'); info 他のブラウザと異なり、Firefoxはミリ秒単位で測定値を提供します。 X-Frame-Optionsを検知する # 埋め込み内にページを表示する場合 (たとえば、X-Frame-Options ヘッダーのため)、Chrome の performance オブジェクトに追加されません。https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/timing-attacks/execution-timing/Thu, 01 Oct 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/timing-attacks/execution-timing/ブラウザ上でのJavaScriptの実行時間を測定することで、攻撃者は特定のイベントがいつ発生したか、ある操作にどれくらいの時間がかかったかといった情報を得ることができます。 イベントループのタイミング # JavaScriptの並行処理モデルは、single-threaded event loopに基づいており、これは一度に一つのタスクしか実行できないことを意味します。 例えば、ある時間のかかるタスクがイベントループをブロックした場合、UIスレッドが枯渇した結果として、ユーザーはページがフリーズしたように感じることがあります。 他のタスクはブロックされたタスクが終了するまで待たなければなりません。 各ブラウザは異なるプロセスモデルを実装しているので、ウェブサイトによっては、その関係によって異なるスレッド（およびイベントループ）で実行されることがあります。 このモデルを悪用して、クロスオリジンページから秘密を盗みだす手法があります。 イベントプールで次に実行されるまでの時間を測定することで、異なるオリジンのコードが実行されるまでの時間を推測する。攻撃者は固定されたプロパティを持つイベントをイベントループ12に送り続け、プールが空になると最終的にディスパッチされます。他のオリジンは同じプールにイベントをディスパッチし、ここで攻撃者はそのタスクの一つで遅延が発生したかどうかを検出することで、時間差を推測します。 攻撃者が制御する文字列によって前記の機密情報が比較される場合、クロスオリジンページから機密情報を盗む。このリークは、1文字ずつの文字列比較2のイベントループで時間差を比較した結果です（前出の手法を使用）。process isolationを行わないブラウザでは、異なるオリジン間のクロスウィンドウ通信が同じスレッドで実行され、同じイベントループを共有します。 important process isolationの仕組みがあるブラウザでは、後者の攻撃の可能性はすでにありません。このような仕組みは、現在Chromiumベースのブラウザでは Site Isolationのみで、Firefox にはProject Fission という名前で間もなく導入される予定です。 Busy Event Loop # 別の手法として、スレッドのイベントループをブロックし、イベントループが再び利用可能になるまでの時間を計測する方法があります。 この手法の主な利点の1つは、攻撃者のオリジンが他のオリジンの実行に影響を与えることができるため、Site Isolationを回避できることです。この攻撃は次のように動作します。 対象のウェブサイトをwindow.openで別ウィンドウに表示するか、iframe内に表示する。(Framing Protectionsが設定されていない場合) 長い計算が始まるのを待つ。 Framing Protectionsに関係なく、同じサイトのページをiframe内に読み込む 攻撃者は、(手順3の)iframeがonloadイベントをトリガーするのにかかった時間を計ることで、ターゲットのウェブサイトが実行された時間を検出できます。(Network Timing of step 3 should be minimal) 両方のナビゲーションは同じコンテキストで発生し、それらは同じサイトであるため、同じスレッドで実行され、同じイベントループを共有します。（それらは互いにブロックすることができます。） // 新しいウィンドウを開いて、example.comのイベントループを // ウィンドウがブロックする時間を測定する window.open('https://example.org/expensive'); // TODO: タイムアウトなどでコストの掛かるウィンドウがロードされるのを待ちます。 var ifr = document.createElement('iframe'); ifr.src = "https://example.org"; document.body.appendChild(ifr); // 初期時間の測定 var start = performance.now(); ifr.onload = () => { // iframeが読み込まれたら、時間差を計算する var time = performance.https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/timing-attacks/hybrid-timing/Thu, 01 Oct 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/timing-attacks/hybrid-timing/ハイブリッド・タイミング攻撃では、攻撃者は最終的なタイミング測定に影響を与える一連の要素の合計を測定することができます。これらの要素には以下のものがあります。 ネットワークの遅延 ドキュメントのパース サブリソースの検索と処理 コード実行 アプリケーションによって値が異なる要素もあります。つまり、Network Timing はバックエンドの処理が多いページでより重要かもしれませんし、一方 Execution Timing はブラウザ内でデータを処理し表示するアプリケーションでより重要かもしれないのです。攻撃者は、より正確な測定値を得るために、これらの要因のいくつかを排除することも可能です。例えば、攻撃者はページを iframe として埋め込むことによってすべてのサブリソースを事前にロードし（ブラウザにサブリソースをキャッシュさせる）、その後、それらのサブリソースの取得によって生じる遅延を除外した2度目の計測を行えます。 Frameタイミング攻撃(Hybrid) # ページがFraming Protectionsを設定していない場合、攻撃者はすべての要素を考慮したハイブリッドな計測結果を取得できます。この攻撃はNetwork-based Attackと似ていますが、リソースが取得されると、ブラウザによってページがレンダリングされて実行されます（サブリソースの取得と JavaScript の実行が行われる）。このシナリオでは、onloadイベントは（サブリソースとスクリプトの実行を含めて）ページが完全にロードされたときだけトリガーされます。 var iframe = document.createElement('iframe'); // 配送先のWebサイトのURLを設定する iframe.src = "https://example.org"; document.body.appendChild(iframe); // リクエストが初期化されるまでの時間を計測する var start = performance.now(); iframe.onload = () => { // iframeが読み込まれたら、時間差を計算する var time = performance.now() - start; console.log("The iframe and subresources took %d ms to load.", time) } 対策 # Attack Alternative SameSite Cookies (Lax) COOP Framing Protections Isolation Policies Frame Timing (Hybrid) ✔️ ❌ ✔️ FIPhttps://webapppentestguidelines.github.io/xs-leaks/docs/attacks/timing-attacks/connection-pool/Thu, 01 Oct 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/timing-attacks/connection-pool/network timingを測定する方法の一つとして、ブラウザのソケットプールを悪用する方法があります。 ブラウザはサーバと通信するために、ソケットを利用します。 ハードウェアやその上で動作するOSのリソースには限りがあるため、ブラウザにも制限をかけざるを得ません。 この制限の存在を悪用するために、攻撃者は下記のようなことができます。 ブラウザの制限を確認する。 単に接続をハングアップさせる \(255\) のリクエストを別々のホストに実行して、長時間 \(255\) のソケットをブロックする。 ターゲットページに対するリクエストを実行して、 \(256^{番目}\) のソケットを利用する。 他のホストへの \(257^{番目}\) のリクエストを実行します。(step2、3で)すべてのソケットが使用されているので、このリクエストは、プールが利用可能なソケットを受け取るまで待機する必要があります。この待ち時間は、ターゲットページに属する \(256^{番目}\) のソケットのネットワークタイミングを、攻撃者に提供します。これが動作するのは、ステップ2の \(255\) 個のソケットがまだブロックされているので、ステップ3のソケットの解放によってプールが利用可能なソケットを受信した場合です。 \(256^{番目}\) のソケットを解放する時間は、リクエストを完了するのにかかった時間と直結しています。 対策 # SameSite Cookies (Lax) COOP Framing Protections Isolation Policies ❌ ❌ ❌ ❌ info partitioned cachesと同様に、リソースの"site/originごとの分割"の原理をソケットプールに拡張することを、いくつかのブラウザが検討しています。 参考文献 #