https://webapppentestguidelines.github.io/xs-leaks/category/historical/Recent content in Historical on XS-Leaks WikiHugo -- gohugo.ioja-jpThu, 01 Oct 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/historical/content-type/Thu, 01 Oct 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/historical/content-type/リクエストのContent-Typeをリークすることで、攻撃者は2つのリクエストを区別できるようになります。 typeMustMatch # typeMustMatchはobject要素のtypeMustMatch属性を反映したブール値です。これは、オブジェクトを読み込む際に、リソースのContent-Typeがオブジェクトで提供されるものと同じかどうかを検証することで、特定の MIME タイプを強制しなければならないことを保証します。残念ながら、この強制は攻撃者がウェブサイトから返されるContent-Typeとステータスコードを漏らすことも可能にします 1。 根本的な原因 # 以下のスニペットを考えると、https://target/api で返された Content-Type が type のものと一致しない場合や、サーバが 200 以外のステータスを返した場合には、 not_loaded がレンダリングされるでしょう。 <object type="application/json" data="https://example.org" typemustmatch> not_loaded </object> 問題 # 攻撃者は、すべての条件が満たされたときに起こるオブジェクトのレンダリングを検出することによって、ウェブサイトのContent-Typeとステータスコードをリークできます。攻撃者は、(ステータスコード200で)オブジェクトがレンダリングされるとき、0ではないであろうclientHeightとclientWidthの値をチェックできます。typeMustMatchはリソースを読み込む際に、サーバーがステータス200を返すことを要求するので、Error Events XS-Leaksと同様にエラーページを検出することが可能でしょう。 以下の例では、iframe内にオブジェクトを埋め込み、iframeがonloadイベントをトリガーしたときにclientHeightとclientWidthの値をチェックすることでこの動作を検出する方法を示しています。 // 配送先のWebサイトのURLを設定する var url = 'https://example.org'; // チェックしたいコンテンツタイプ var mime = 'application/json'; var ifr = document.createElement('iframe'); // オブジェクトがonloadイベントを発生させないので、iframe内にオブジェクトをロードする。 ifr.srcdoc = ` <object id="obj" type="${mime}" data="${url}" typemustmatch> error </object>`; document.body.appendChild(ifr); // iframeが読み込まれたら、オブジェクトの高さを読み取ります。 // もしそれが一行のテキストの高さであれば、リソースのContent Typeは`application/json`ではなかったということです。 // もしそうでなければ、それは`application/json`だったということです。 ifr.onload = () => { console.https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/historical/stateful-browser-features/Thu, 01 Oct 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/historical/stateful-browser-features/ブラウザの機能/拡張の中には、ブラウザによって生成された特定のウェブサイトの状態に応じて、リクエストの処理方法を変更するものがあります。攻撃者は、時に、このプロセス全体を観察し、ブラウザを混乱させ、これらの状態に対して副作用をもたらすアクションを引き起こすことができます。 WebKit – ITP # Intelligent Tracking Prevention (ITP) は、WebKit Tracking Prevention technologies の一部であるプライバシー機能です。これは、いくつかの機能を組み合わせたもので、ウェブサイトが第三者のコンテキストの下でユーザーを追跡することを防ぐことを目的としています。残念ながら、残念ながら、初期の設計では新しいXS-Leak1が登場し、ITPが暗黙的に作り出した状態を攻撃者が悪用して、ウェブサイトをトラッカーとすることができました。 根本的な原因 # ITPは、Webサイトにトラッキング機能があるかどうかを分類するために、リソースの負荷や、クリック、タップ、テキスト入力など、Webサイトに対するユーザーのインタラクションに関する統計情報を収集しています。ITPは、これらの統計情報を分類し、トラッキング機能があると思われるWebサイトにはストライクを与えます。3回ストライクを受けると、そのウェブサイトは拒否リストに登録され、今後のリクエストの際にブラウザによって扱いが変更されます。 問題 # ITPの問題の1つは、攻撃者がITPを操作して、特定の動作を任意に強制できることです。たとえば、攻撃者はITPを操作して、あるドメインにストライクを与え、そのドメイ ンが拒否リストに入ったかどうかをチェックすることができます。この情報は、たとえば次のようなさまざまな方法で活用することができます。 ドメインが拒否リストに入るために必要なストライクの数に基づいて、ユーザーのブラウジング習慣をリークします。 拒否リストを利用して、結果があるときだけクロスサイトリソースを取り込むページに対してXS-Search攻撃を実行します。 修正 # この問題を修正するため、ITPは分類をやめ、すべてのサイトをデフォルトで「トラッキング」サイトと見なすようになりました。これにより、攻撃者が特定のITPの動作を検出することを可能にしていた暗黙的状況がなくなりました。 参考文献 # Information Leaks via Safari’s Intelligent Tracking Prevention, link ↩︎