https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/Recent content in 攻撃手法 on XS-Leaks WikiHugo -- gohugo.ioja-jphttps://webapppentestguidelines.github.io/xs-leaks/docs/attacks/xs-search/Thu, 01 Oct 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/xs-search/XS-Search（クロスサイトサーチ）は、XS-Leaksのファミリーの中で重要な攻撃原理です。 この種の攻撃は、クエリベースの検索システムを悪用し、攻撃者のオリジンからユーザー情報をリークさせます1 2。 元々の攻撃は、検索システムが結果を返すかどうかを検出するためにレスポンス時間を用いて、以下のように行います。 リクエストの結果がヒットした場合の時間(hit）と、結果がヒットしなかった場合の時間(miss)を計測する。 検索エンドポイントへのリクエストに対して、timing attackを開始し、最初の文字 (?q=r) をブルートフォースで攻撃する。 2.で計測した時間が1.で計測したhitである場合、もう一文字追加する (?q=ra); そうでなければ、新しい文字 (?q=s) を試す。 最終的に、完全なシークレット(?q=secret)を取得できる。 この攻撃は、正確さを期すために複数のタイミング測定が必要であり、インフレーション技術や統計分析によって改善することができます。 さらに、一文字ずつブルートフォースするのではなく、攻撃者は特定の単語や文章を検索して結果の出現箇所のみを漏洩させることができます。 この攻撃の最も重要な部分はその原理であり、様々なXS-Leaksに適用することが可能です。 レスポンス時間の増加方法 # XS-Searchのインフレーション技術は、2つのレスポンス（hitまたはmiss）を区別しやすくすることで攻撃の精度を上げるために使用されます。 以下の2つのメカニズムにより、攻撃者はより適切な計測を行うことができます。 検索システムが結果を返す際に、特定のGETパラメータをレスポンスに反映させるとレスポンスのサイズが大きくなる。これによりレスポンスをネットワーク上に送信する時間が大幅に増加するため、リクエストをより区別しやすくする。 レスポンスを返す前に、サーバーにさらに計算作業を実行させる。この方法は、より表現力の高いクエリー言語を提供する検索システムに適用できる。（例：Gmailのexclude termsは結果内のすべての文字を処理する） 拡張原理 # XS-Search に関するオリジナルの研究はタイミング攻撃に焦点を当てていましたが、この攻撃の原理は他の XS-Leak にも拡張することができます。 前述のように信頼性の低いタイミング測定に頼るのではなく、攻撃者は他の XS-Leak を利用して同じ情報を抽出することができます。 クエリベースの検索システムでは、ユーザーはクエリを送信し、そのクエリに関連するレスポンスを取得します。 この動作は、2つの異なる結果をもたらす可能性があります。 システムが結果を表示し、ページが特定の動作をする(第1の状態)。 システムが結果を表示せず、ページがステップ1とは異なる方法で動作する(第2の状態)。 上記の両方の挙動をタイミングよりも信頼性の高い XS-Leak で区別できる場合、攻撃者はより効率的な XS-Search 攻撃を行うことができます。 例えば、検索結果によってページのフレーム数が変化する（ステップ1と2が区別できる）場合、この攻撃原理は Frame Counting XS-Leak を適用することができるため、タイミング測定を使用するよりも正確である可能性があります。 対策 # Attack Alternative SameSite Cookies (Lax) COOP Framing Protections Isolation Policies XS-Search (timing) ✔️ ❌ ❌ RIP 🔗 NIP 🔗 – 異なるシナリオに対して有効な防御機構を組み合わせる必要がありますhttps://webapppentestguidelines.github.io/xs-leaks/docs/attacks/window-references/Thu, 08 Oct 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/window-references/もしページが opener プロパティを null に設定したり、ユーザーの状態に応じて COOP による保護を使用している場合、その状態に関するクロスサイト情報を推測することができます。 例えば、攻撃者は認証されたユーザーのみがアクセスできる iframe (または新しいウィンドウ) でエンドポイントを開き、そのウィンドウの参照をチェックするだけで、ユーザーがログインしているかどうかを検出することができます。 コード # 以下のコードは、open プロパティが null に設定されているかどうか、あるいは COOP ヘッダーが unsafe-none 以外の値で存在するかどうかを検出する方法を示しています。 これは、iframeと新しいウィンドウの両方で行うことができます。 // 脆弱な攻撃対象URL const v_url = 'https://example.org/profile'; const exploit = (url, new_window) => { let win; if(new_window){ // 新しいタブを開き、win.opener が COOP の影響を受けたか、あるいは null に設定されたかどうかを確認 win = open(url); }else{ // opener が定義されているかどうかを検出するために iframe を作成 // COOP の検出や、ページがフレーム保護を実装している場合は機能しない document.body.insertAdjacentHTML('beforeend', '<iframe name="xsleaks">'); // iframeを脆弱な攻撃対象URLにリダイレクトする win = open(url, "xsleaks"); } // ページのロードを2秒待つ setTimeout(() => { // 新しく開いたウィンドウのオープナープロパティを確認する if(!https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/css-tricks/Thu, 01 Oct 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/css-tricks/CSS Tricks # CSSを利用して視覚的な変化を起こすことで、ユーザーが埋め込みピクセル値などの情報を暴露するように騙すことができます。 ユーザのヒストリーを取得する # CSSの:visitedセレクタを使うと、訪問したことのある URL に対して異なるスタイルを適用することができます。 以前はgetComputedStyle()を使ってこの違いを検出することができましたが、昨今のブラウザでは常にリンクが訪問されたかのような値を返すことでこれを防ぎ、セレクタを使って適用できるスタイルを制限しています。1 そこで、CSSが効いた領域をクリックするようにユーザーを誘導する必要があるかもしれませんが、これはmix-blend-modeを使って行うことができます。2 また、レンダリングタイミングを悪用することで、ユーザーとのインタラクションなしに、リンクを別の色に塗り替える方法もあります。3 複数のリンクを使用して時間差を増加させることで動作するPoCがchromium report上で提供されました。3 info この攻撃例[^leak-1]は、もぐらたたきゲームを利用してユーザーをだましてページをクリックさせるものです。この問題に関して複数のブラウザにバグが報告されています。: ^bug-1, ^bug-2, ^bug-3 Captchaの悪用 # CSSを使えば、埋め込みをコンテキストから外部に取り出せます。 この例として、4に見られるようなcaptchaのふりをすることが挙げられます。 これは、埋め込み部分の幅と高さを設定することで、狙った文字だけが表示されるようにするものです。 複数の埋め込みを利用して、表示される文字の順番を変えて、何の情報を提供しているのかをユーザーが分かりづらくすることも可能です。 オートコンプリートの悪用 # テキスト入力を使用するウェブサイトで、autocomplete="off"を使用してオートコンプリートを無効にしない場合、電子メールアドレスなどのデータをリークできる場合があります。javascriptを使用したテキスト入力のオートコンプリート機能を利用するために、ユーザーを騙して、キーを押させることができます。 Chromeの場合、上または下矢印キーを押してダイアログを開き、値を選択した後、EnterキーまたはTabキーを押して値をページに挿入するようにユーザーを誘導することが必要です。 let input = document.createElement("input"); input.type = "email"; input.autocomplete = "email"; input.name = "email"; input.size = "1"; input.style = "position:absolute;right:-500px;bottom:-21.9px"; input.onkeypress = e => { e.preventDefault(); } window.onmousedown = e => { // マウスのクリックを無視する e.preventDefault(); } input.onchange = e => { alert(e.https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/error-events/Thu, 01 Oct 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/error-events/Webページがサーバにリクエストを発行すると（例：フェッチ、HTMLタグ）、サーバはこのリクエストを受信して処理します。 受信した際にサーバは与えられた条件に基づいて、リクエストが成功（例：200）すべきか失敗（例：404）すべきかを決定します。 レスポンスがエラーステータスを持つ場合、ページを処理するためにブラウザによってerror eventが発行されます。 これらのエラーは、例えばHTMLコンテンツを画像として埋め込もうとした時のようなパーサーの処理が失敗するケースにも対応しています。 たとえば、攻撃者は認証されたユーザだけが利用できるリソースにユーザがアクセスできるかどうかを確認することで、ユーザがサービスにログインしているかどうかを検出できます1。 このXS-Leakの影響はアプリケーションによって異なりますが、ユーザを非匿名化する高度な攻撃につながる可能性があります2。 エラーイベントは様々な HTMLタグからスローされる可能性があり、ブラウザによって動作が異なるものもあります 3。 例えば、読み込まれたリソースやHTMLタグ、特定のヘッダ（例えば nosniff や Content-Type ）の存在、あるいはブラウザのデフォルトの保護機能の適用などによって動作が変わることがあります。 エラーイベントで情報をリークさせる原理は、さまざまなXS-Leakに抽象化して適用できます。 たとえば、Cache Probingの1つの手法では、特定の画像がブラウザによってキャッシュされたかどうかの検出にエラーイベントを使用しています。 コード # 以下のコードは、<script> タグを使用してエラーイベントを検出する方法を示しています。 function probeError(url) { let script = document.createElement('script'); script.src = url; script.onload = () => console.log('Onload event triggered'); script.onerror = () => console.log('Error event triggered'); document.head.appendChild(script); } // google.com/404 が HTTP 404 を返すため、スクリプトはエラーイベントを発生する probeError('https://google.com/404'); // google.com は HTTP 200 を返すので、スクリプトは onloadイベントをトリガーする probeError('https://google.com/'); 対策 # このXS-Leakの緩和策は、アプリケーションが特定のリソースをどのように処理するかによって異なる可能性があります。 一般的なアプローチとしては、可能な限り一貫した挙動を採用することです。 特定のシナリオでは、アプリケーションはSubresource Protectionsを使用して、攻撃者がURLを予測して攻撃を進行させることを防ぐことができます。 最後に、一般的なWebプラットフォームのセキュリティ機能を導入することで、アプリケーションの実装に大きな変更を加えることなく、このXS-Leakをより大幅に緩和することができます。https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/frame-counting/Thu, 01 Oct 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/frame-counting/ウィンドウの参照により、クロスオリジンのページが他のページのいくつかの属性にアクセスできます。 これらの参照は、iframeとwindow.openを使用または許可するときに利用可能となります。 この参照は、同一生成元ポリシーを尊重し続けるため、ウィンドウに関する（限定的な）情報を提供します。 アクセス可能な属性の1つは、ウィンドウ内のフレーム数を提供するwindow.lengthです。 この属性は、ページに関する貴重な情報を攻撃者に提供します。 Webサイトでは一般的にフレーム（またはiframes）を使用しますが、この選択は必ずしもセキュリティ上の問題を意味するわけではありません。 しかし、Webサイトがユーザの情報に応じてページのフレーム数を変更する場合があります。 例えば、GETパラメータと利用者のデータに応じてレイアウトを変えるようなページで起こりえます。 攻撃者は、異なるページで window.length の値を測定することにより、被害者に関する情報を推測することが可能かもしれません。 コード # 以下のコードは、クロスサイトのページにおけるフレーム数に関する情報にアクセスする方法を示しています。 // ウィンドウへの参照を取得する var win = window.open('https://example.org'); // ページが読み込まれるのを待つ setTimeout(() => { // 読み込まれたiframeの数を読み取る console.log("%d iframes detected", win.length); }, 2000); 攻撃の対策 # 場合によっては、異なるアプリケーション状態が同じ数のフレームを持つことで、攻撃者がそれらを区別できないようにすることができます。 ただし、ページの読み込み中にフレーム数を連続的に記録することで、攻撃者に情報をリークする可能性があるパターンを示す可能性もあります。 // ウィンドウへの参照を取得する var win = window.open("https://example.org"); var pattern = []; // ループ内で、60ms間隔でiframeの数を登録する var recorder = setInterval(() => { pattern.push(win.length) }, 60); // 6秒後にループを解除する setTimeout(() => { clearInterval(recorder); console.log("The pattern is: %s", pattern.join(', ')); }, 6 * 1000); 事例 # フレームカウント攻撃の例としては、以下のようなものがあります。https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/navigations/Thu, 01 Oct 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/navigations/クロスサイトのページで画面遷移がトリガーされたか（または、そうでないか）を検出することは攻撃者にとって有用です。例えば、ウェブサイトはユーザの状態に依存(#case-scenarios)して、あるエンドポイントで画面遷移をトリガーする可能性があります。 どのような画面遷移が発生したかを検出することで攻撃者以下の様なことが可能になります。 iframeを使用してonloadイベントがトリガーされた回数を数える。 ウィンドウへの参照を通じてアクセス可能なhistory.lengthの値をチェックする。この値は被害者のhistory.pushStateや通常の画面遷移によって変更された履歴の数を提供しています。攻撃者はhistory.lengthの値を取得するためにウィンドウへの参照のlocationをターゲットのウェブサイトに変更し、そしてSame-Originに戻すことによって最後に値を読み取ります。 ダウンロードトリガー # エンドポイントがContent-Disposition: attachment ヘッダを設定すると、ブラウザにレスポンスをナビゲートさせるのではなくファイルとしてダウンロードすることを指示します。この挙動が発生したかを検出すると、結果が被害者の状態に依存する場合に攻撃者に機密情報をリークできる可能性があります。 ダウンロードバー # Chromeベースのブラウザではファイルをダウンロードする際に、ブラウザのウィンドウ下部にダウンロードの進捗を示すバーがウィンドウと一体化して表示されます。攻撃者ウィンドウの高さを監視することでダウンロードバーが開いているかどうかを検出することができます。 // ウィンドウの現在の高さを読み取る var screenHeight = window.innerHeight; // ダウンロードのトリガーとなるページを読み込む window.open('https://example.org'); // タブの読み込みを待つ setTimeout(() => { // ダウンロードバーが表示された場合、すべてのタブの高さが小さくなります if (window.innerHeight < screenHeight) { console.log('Download bar detected'); } else { console.log('Download bar not detected'); } }, 2000); important この攻撃は、自動ダウンロード機能が有効になっているChromeベースのブラウザでのみ有効です。加えてこの攻撃はユーザがダウンロードばーばを能動的に閉じないと再検出できないため、繰り返し行うことはできません。 iframeを利用したダウンロード遷移 # Content-Disposition: attachment ヘッダをテストするもう一つの方法は遷移が発生したかどうかをチェックすることです。仮にページの読み込みによってダウンロードが発生した場合、遷移は発生せずウィンドウは同一オリジン内に留まります。 以下のコードは、そのような遷移が発生したかを検出しダウンロードが試行されたかを検出します。 // ダウンロード試行時のテスト先URLを設定する var url = 'https://example.org/'; // onloadイベントを計測するための外側のiframeを作成する var iframe = document.createElement('iframe'); document.body.appendChild(iframe); // ダウンロードの試行をテストするために、内側のiframeを作成 iframe.srcdoc = `<iframe src="${url}" ></iframe>`; iframe.https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/cache-probing/Mon, 01 Jan 0001 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/cache-probing/Cache Probingは、あるリソースがブラウザによってキャッシュされているかどうかを検知する手法です。そのコンセプトは、初期のWeb1から知られており、当初はタイミングの差異を検知することに基づいていました。 ユーザがWebサイトに訪れると、画像、スクリプト、そしてHTMLコンテンツなどの様々なリソースが取得され、それらは(特定の条件下で)ブラウザによってキャッシュされます。この最適化により、ブラウザはこれらのリソースを再度要求することなくディスクから提供するため、その後のナビゲーションが高速化されます。もし攻撃者がどのリソースがキャッシュされているかを検知できれば、この情報を基に、ユーザが特定のページにアクセスしたことがあるかどうかをリークできます。 Cache Probingのバリエーションとして、Error Eventsを悪用することにより、より正確でインパクトのある攻撃を実行することができます。 攻撃の原理 # 攻撃者は、あるユーザーがあるSNSを訪問したかどうかを知りたいと考えています。 そのSNSにアクセスすると、いくつかのサブリソースがキャッシュされます。 ユーザが、SNSが通常取得するリソースを取得する攻撃者のページを訪問する。 Network Timing XS-Leakの手法を用いて、攻撃者のページはキャッシュからの応答（つまりステップ1が起こった）とネットワークからの応答（つまりステップ1が起こらなかった）の違いを検出することができます。（応答がキャッシュからの場合、遅延は顕著に短くなります。） Error EventsによるCache Probing # Error Events2を利用したキャッシュプロービングは、より正確な攻撃を可能にします。このアプローチでは、時間の計測に頼らず、Error Eventsといくつかのサーバサイドの挙動を活用して、あるリソースがキャッシュされたかどうかを検出します。この攻撃は、以下のステップを必要とします。 ブラウザキャッシュからのリソースを無効化する。このステップは、攻撃が別の訪問で以前にキャッシュされたリソースを考慮しないことを確認するために必要です。 ユーザーの状態によって異なる項目がキャッシュされるようなリクエストを実行する。例えば、ユーザーがログインしている場合にのみ、特定の画像を含むページをロードする。このリクエストは、<link rel=prerender...で対象のウェブサイトに移動したり、iframeでウェブサイトを埋め込んだり、window.openで新しいウィンドウを開くことで発生させることができる。 サーバが拒否するようなリクエストを引き起こす。例えば、長大なRefererヘッダを含んでいて、サーバーがリクエストを拒否するような場合です。もし、ステップ2でリソースがキャッシュされていれば、このリクエストはエラーイベントを発生させることなく、成功します。 キャッシュの無効化 # キャッシュからのリソースを無効にするには、攻撃者はそのサブリソースを取得する際にサーバーがエラーを返すようにする必要があります。これを実現するには、いくつかの方法があります。 ブラウザによってリクエストが開始され、新しいコンテンツを受け取る前にAbortController.abort()で中止された cache:'reload'オプション付きのフェッチリクエスト 長大なRefererヘッダと 'cache':'reload'を持つリクエスト。ブラウザはこれを防ぐためにリファラの長さに上限を設けているので、これはうまくいかないかもしれません。 POSTリクエストに fetch no-cors を指定した場合。エラーが返されない場合でも、ブラウザがキャッシュを無効化することがあります。 Content-Type、Accept、Accept-Languageなど、サーバーを失敗させる可能性のあるリクエストヘッダ。（よりアプリケーションに依存します） その他のリクエストプロパティ これらの方法のいくつかは、しばしばブラウザのバグとみなされていそうです。(例: this bug). Origin ReflectionによるCORS error # Origin Reflectionは、グローバルにアクセス可能なリソースに、リクエストを初期化したオリジンを反映したAccess-Control-Allow-Origin（ACAO）ヘッダを付与する挙動のことです。これは、CORSの設定ミス3と考えることができ、ブラウザのキャッシュにリソースが存在するかどうかを検知するのに使用できます。 info 例えば、Flask frameworkにおいて、origin refrectionはデフォルトの動作になっています。 もし server.com にホストされているリソースが target.com からリクエストされた場合、オリジンはレスポンスヘッダに次のように反映されるでしょう。Access-Control-Allow-Origin: target.com といった具合です。リソースがキャッシュされている場合、この情報はリソースと一緒にブラウザのキャッシュに保存されます。これにより、もし attacker.com が同じリソースを取得しようとした場合、2つの可能性があります。 リソースがキャッシュにない場合：リソースは Access-Control-Allow-Origin: attacker.com ヘッダーとともにフェッチされ、保存される可能性があります。 リソースがすでにキャッシュにある：フェッチ試行はキャッシュからリソースをフェッチしようとするが、要求しているオリジンと ACAO ヘッダーの値の不一致によりCORSエラーが起こる。（target.comが期待されているが、実際に提供されたのはattacker.com 。）以下に、この脆弱性を悪用して被害者のブラウザのキャッシュ状態を推測するコード例を示します。 // この関数は、単にURLを受け取り、CORS モードでfetchします。 // fetchでエラーが発生した場合、attacker.https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/element-leaks/Mon, 01 Jan 0001 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/element-leaks/一部のHTML要素は、クロスオリジンのページにデータの一部をリークさせるために使用される可能性があります。 たとえば、以下のようなメディアリソースは、サイズ、期間、種類に関する情報をリークさせる可能性があります。 HTMLMediaElementは、メディアのdurationとbufferedの時間をリークします。 HTMLVideoElement はvideoHeightとvideoWidthをリークします。一部のブラウザでは、webkitVideoDecodedByteCount、 webkitAudioDecodedByteCount、webkitDecodedFrameCountも含む可能性があります getVideoPlaybackQuality()はtotalVideoFramesをリークします。 [HTMLImageElement]（https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement）はheightとwidthをリークしますが、画像が無効な場合には、それらは0となり、image.decode()は拒否されます。 メディアタイプの固有のプロパティによって、メディアタイプを区別することができます。 たとえば、<video>の場合はvideoWidth、<audio>の場合はdurationといった具合です。 以下のコードは、リソースの種類を返すサンプルコードを示しています。 async function getType(url) { // リソースがaudioもしくはvideoかどうかを検知 let media = document.createElement("video"); media.src = url; await new Promise(r=>setTimeout(r,50)); if (media.videoWidth) { return "video"; } else if (media.duration) { return "audio" } // リソースがimageかどうかを検知 let image = new Image(); image.src = url; await new Promise(r=>setTimeout(r,50)); if (image.width) return "image"; } CORBの悪用 # CORB は、間違ったコンテンツタイプが使用された場合にレスポンスを空にするChromeの機能です。 これは、コンテンツタイプが間違っている場合、キャッシュされないことを意味します。 ifCached 関数についてはCache Probingの記事にて確認できます。 async function isType(url, type = "script") { let error = false; // urlをパージする await ifCached(url, true); // リソースの読み込みを試行 let e = document.https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/id-attribute/Thu, 01 Oct 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/id-attribute/id属性はHTML要素を識別するために広く利用されています。残念ながらクロスオリジンのウェブサイトでfocusイベントとURLフラグメントを利用することによって、ページのどこにid属性が与えられているかを決定することができます。例えば、https://example.com/foo#barが読み込まれると、ブラウザはid="bar"が与えられた要素までスクロールしようとします。これはクロスオリジンのサイトで定義したiframeでhttps://example.com/foo#barを読み込むことによって検出することができます。もし、 id="bar" を持つ要素がある場合は、 focus イベントが発生します。 focus イベントもまた同じ目的で使用することができます1。 いくつかのウェブアプリケーションはfocusable要素にid属性を設定しており、ユーザ情報の開示につながります。これらのid属性には、ユーザに直接関連する機密情報やユーザの状態（アカウントの状態）に関連する情報を含めることができます。 コード # 以下のコードは別のサイトからID属性を検出する例を示しています： // onblurイベントをリッスン onblur = () => { alert('Focus was lost, so there is a focusable element with the specified ID'); } var ifr = document.createElement('iframe'); // ページに id="x" のフォーカス可能な要素がある場合、フォーカスを得ることができます。 // 例： <input id="x" value="test" /> ifr.src = 'https://example.org/#x'; document.body.appendChild(ifr); info 上記の手法はFireFoxではうまく動作しない可能性があります。 攻撃シナリオ # id属性を利用した攻撃は以下のような物があります。 とある銀行がモバイルデバイスのセッションを認証するために短い数字のワンタイムPin(OTP)を生成することを許可しています。この銀行のページはクライアントにPINコードを表示するためのbutton要素のidにOTPコードそのものを使用していました。この挙動を悪用し、すべてのオプションをブルートフォースすることでOTPコードを窃取し、ユーザアカウントを侵害することができます。 とあるウェブアプリケーションが、プレミアムアカウントのステータスを持つユーザや、特定の性別のユーザである場合、あらかじめ定義されたidとHTML要素の組み合わせを利用します。攻撃者は、被害者のページに特定のidがあるかを検出し、被害者のアカウント情報を漏えいさせることができます。 対策 # Document Policies SameSite Cookies (Lax) COOP Framing Protections Isolation Policies ✔️ ✔️ ✔️ ❌ FIP 参考文献 # Leaking IDs using focus, link ↩︎https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/postmessage-broadcasts/Thu, 01 Oct 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/postmessage-broadcasts/アプリケーションは、他のオリジンと情報を共有するために、しばしば postMessage broadcasts を使用します。 postMessage を使うと、2種類の XS-Leaks につながる可能性があります。 信頼できない発信元と機密性の高いメッセージを共有すること postMessage API は targetOrigin パラメータをサポートしており、これを使用してメッセージを受信できるオリジンを制限することができます。メッセージに機密性の高いデータが含まれている場合、このパラメータを使用することが重要です。 変化するコンテンツやブロードキャストの存在に基づいた情報のリーク 他の XS-Leak のテクニックと同様に、これはオラクルを形成するために使われる可能性があります。例えば、特定のユーザ名を持つユーザが存在する場合にのみ、アプリケーションが「Page Loaded」という postMessage ブロードキャストを送信すると、これを利用して情報をリークすることができます。 対策 # この XS-Leak は、postMessage のブロードキャスト送信の目的に深く依存するため、明確な解決策はありません。 アプリケーションは、postMessage の通信を既知の送信元グループに制限する必要があります。 これが不可能な場合、攻撃者が通信間の違いに基づいて情報を推論するのを防ぐために、ユーザの状態に関係なく通信が一貫して同じ動作をする必要があります。 References #https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/css-injection/Mon, 01 Jan 0001 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/css-injection/CSSインジェクション # warning ここで紹介される一連のXS-Leaksは対象ページでのCSSインジェクションを必要とします。 CSSインジェクションの様々なベクトルの中で、最もよく見られるのは、CSSセレクタの悪用です。これらは、特定のHTML要素にマッチし、選択するための表現として使用することができます。例えば、セレクタ input[value^="a"] は、input タグの値が文字 “a” で始まっている場合にマッチングされます。したがって、ある CSS セレクタが表現にマッチするかどうかを検出するため、攻撃者は background や @import などのプロパティを使用して、自身の管理するウェブサイトへのコールバックをトリガーすることができます。1 2 このマッチングプロセスは簡単にブルートフォースされ、文字列全体に拡張できます。 文字の並びに独自の表記がある場合、フォントの合字を悪用して、ページに含まれるJavaScriptなどがリークされる可能性があります。 * { display: block; }のようなスタイルを適用すると、styleやscriptなどの通常は隠されているHTMLタグも、テキストとして表示されることがあります。したがって、それらの内容もリークされる可能性があります。 対策 # 攻撃者がコントロールするコンテンツを独立したドキュメントに置きます。これは srcdoc属性を持つiframeを使って行うことができます。オプションで、コンテンツを独自のオリジンに分離するためのサンドボックス属性を含めることができます。 CSSインライナーを使って、グローバルなスタイルが変換されるようにします。 SameSite Cookies (Lax) COOP Framing Protections Isolation Policies ❌ ❌ ❌ ❌ References # CSS Injection Primitives, link ↩︎ HTTPLeaks, link ↩︎