Loading article…
クロスサイト リーク( XS リークとも呼ばれる) は、別の Web サイトにあるユーザーの機密情報にアクセスするために使用される攻撃の種類を表すインターネット セキュリティ用語です。クロスサイト リークにより、攻撃者はユーザーの他の Web サイトとのやり取りにアクセスできます。これには機密情報が含まれる場合があります。通常、 Web ブラウザーは他の Web サイトがこの情報を見るのをブロックします。これは、同一生成元ポリシーと呼ばれる一連のルールによって適用されます。攻撃者は、「クロスサイト リーク」を使用してこれらのルールを回避することがあります。クロスサイト リークを使用する攻撃は、多くの場合、ユーザーを攻撃者の Web サイトにアクセスするように誘導することによって開始されます。攻撃者は、訪問すると、自分の Web サイトで悪意のあるコードを使用して別の Web サイトとやり取りします。攻撃者はこれを使用して、他の Web サイトでのユーザーの以前の行動を知ることができます。この攻撃からの情報により、攻撃者はユーザーを 一意に識別できます。
これらの攻撃は 2000 年から記録されています。このトピックに関する最初の研究論文の 1 つは、パデュー大学の研究者によって発表されました。この論文では、 Web キャッシュを悪用して Web サイトに関する情報を収集する攻撃について説明されていました。それ以来、クロスサイト リークはますます巧妙化しています。研究者は、さまざまな Web ブラウザー コンポーネントを狙った新しいリークを発見しています。これらの手法の有効性はさまざまですが、新しい手法が継続的に発見されています。古い方法の中には、ブラウザー ソフトウェアの更新によってブロックされるものもあります。インターネットの機能の導入と削除によっても、一部の攻撃が無効になっています。
クロスサイト リークは多様な形態の攻撃であり、このような攻撃には一貫した分類がありません。複数のソースが、情報を漏らすために使用される手法によってクロスサイト リークを分類しています。よく知られているクロスサイト リークには、Web ブラウザー内のタイミング イベントに依存するタイミング攻撃があります。エラー イベントは別のカテゴリを構成し、イベントの有無を使用してデータを開示します。さらに、キャッシュ タイミング攻撃は、Web キャッシュを使用して情報を明らかにします。2023 年以降、オペレーティング システムと Web ブラウザーの制限を使用して情報を漏らす新しい攻撃も発見されています。
2017 年以前は、クロスサイト リークの防御は難しいと考えられていました。これは、クロスサイト リーク攻撃で悪用される情報漏洩の問題の多くが、Web サイトの動作に固有のものだったためです。この種類の攻撃に対する防御のほとんどは、2017 年以降、ハイパーテキスト転送プロトコル(HTTP) の拡張機能の形で導入されました。これらの拡張機能により、Web サイトはブラウザーに、他の Web サイトからの特定の種類のステートフルリクエストを禁止または注釈付けするように指示できます。ブラウザーが実装した最も成功したアプローチの 1 つは、 SameSite Cookie です。SameSite Cookie を使用すると、Web サイトは、他の Web サイトが機密性の高い Cookie にアクセスして送信することを防ぐディレクティブを設定できます。別の防御策では、HTTP ヘッダーを使用して、特定のサイトを埋め込むことができる Web サイトを制限します。キャッシュ パーティショニングもクロスサイト リークに対する防御として機能し、他の Web サイトが Web キャッシュを使用してデータを盗み出すことを防ぎます。
背景
Web アプリケーション(Web アプリ) には、Web ブラウザーと 1 つ以上のWeb サーバーという 2 つの主要なコンポーネントがあります。ブラウザーは通常、ハイパーテキスト転送プロトコル(HTTP) およびWebSocket接続を介してサーバーと対話し、 Web アプリを配信します。[注 1] Web アプリを対話型にするために、ブラウザーはHTMLとCSSもレンダリングし、 Web アプリによって提供されるJavaScriptコードを実行します。これらの要素により、Web アプリはユーザーの入力に反応し、クライアント側のロジックを実行できます。[2]多くの場合、ユーザーは長期間にわたって Web アプリと対話し、サーバーに複数のリクエストを送信します。このようなリクエストを追跡するために、Web アプリは現在のセッションまたはユーザー アカウントを通じて特定のユーザーに関連付けられた永続的な識別子を使用することがよくあります。[3]この識別子には、年齢やアクセス レベルなど、Web アプリでのユーザーの履歴を反映する詳細を含めることができます。他の Web サイトに公開された場合、これらの識別可能な属性によってユーザーの匿名性が失われる可能性があります。 [4]
理想的には、各ウェブアプリは他のアプリに干渉することなく独立して動作する必要があります。しかし、ウェブの初期に行われたさまざまな設計上の選択により、ウェブアプリは定期的に相互にやり取りすることができます。[5]この動作の悪用を防ぐために、ウェブブラウザは、異なるソースからのウェブアプリケーション間の直接的なやり取りを制限する、同一オリジンポリシーと呼ばれる一連のルールを適用します。 [6] [7]これらの制限にもかかわらず、ウェブアプリは、ページ上の要素の表示手順、デザインレイアウト、ビデオや画像など、外部ソースからコンテンツを読み込む必要があることがよくあります。クロスオリジンリクエストと呼ばれるこれらのタイプのやり取りは、同一オリジンポリシーの例外です。[8]これらは、クロスオリジンリソース共有（CORS）フレームワークと呼ばれる一連の厳格なルールによって管理されています。CORSは、ウェブアプリが表示できないデータへの不正アクセスを防ぐことで、このようなやり取りが制御された条件下で行われるようにします。これは、他のウェブサイトがこれらのリクエストの内容にアクセスする前に明示的な許可を要求することで実現されます。[9]
クロスサイトリークにより、攻撃者は同一生成元ポリシーと CORS フレームワークによって課せられた制限を回避することができます。これは、ブラウザにこれまで存在していた情報漏洩の問題 (サイドチャネル) を悪用します。これらのサイドチャネルを使用すると、攻撃者は同一生成元ポリシーによって保護されていたデータの詳細を推測できるコードを実行できます。 [10]このデータを使用して、ユーザーが以前に Web アプリとやり取りした内容に関する情報を明らかにすることができます。[11]
機構
-
第三者が存在しない場合は、ユーザーのブラウザが Web サーバーにHTTPリクエストを送信します。サーバーはリクエストの性質に応じて応答を送信します。 -
-
攻撃者は Web サーバーの応答を読み取ることができません。ただし、応答時間やサイズなどの他の要素は攻撃者が測定できるため、応答に関する情報が漏洩する可能性があります (サイドチャネル攻撃)。
クロスサイトリーク攻撃を実行するには、攻撃者はまずウェブサイトがユーザーとどのようにやり取りするかを研究する必要があります。攻撃者は、ユーザーのサイト上での過去の行動に基づいて、異なるハイパーテキスト転送プロトコル(HTTP) 応答を生成する特定のURL を特定する必要があります。 [12] [13]たとえば、攻撃者がGmail を攻撃しようとしている場合、ユーザーのメール内で特定の検索語に対して見つかった検索結果の数に基づいて、異なる HTTP 応答を返す検索 URL を見つけようとします。[14]攻撃者が特定の URL を見つけると、ウェブサイトをホストし、フィッシングを行うか、その他の方法で無防備なユーザーをそのウェブサイトに誘い込むことができます。被害者が攻撃者のウェブサイトにアクセスすると、攻撃者はさまざまな埋め込み手法を使用して、攻撃者が特定した URL へのクロスオリジン HTTP リクエストを開始できます。[15]ただし、攻撃者は別のウェブサイトにアクセスしているため、ウェブブラウザによって課せられた同一オリジンポリシーにより、脆弱なウェブサイトから送信された応答のいかなる部分も攻撃者が直接読み取ることはできません。[注 2] [16]
このセキュリティ障壁を回避するために、攻撃者はブラウザリーク手法を使用して、異なる応答の微妙な違いを区別することができます。ブラウザリーク手法とは、Webブラウザにおける長年の情報漏洩問題（サイドチャネル）を利用してHTTP応答に関する特定の特性を明らかにするJavaScript、CSS 、またはHTMLスニペットです。 [12] [13] Gmailの場合、攻撃者はJavaScriptを使用して、検索結果から返されたHTTP応答をブラウザが解析するのにかかった時間を計測することができます。エンドポイントから返された応答の解析にかかる時間が短ければ、攻撃者はクエリに対する検索結果がなかったと推測することができます。あるいは、サイトの解析に時間がかかった場合、攻撃者は複数の検索結果が返されたと推測することができます。[14]攻撃者はその後、これらの情報漏洩を通じて得た情報を使用して機密情報を盗み出し、被害者を追跡して匿名化を解除することができます。 [15] Gmailの場合、攻撃者は検索エンドポイントにクエリをリクエストし、その後クエリにかかった時間を測定して、ユーザーが特定のクエリ文字列を含むメールを持っているかどうかを調べることができます。[注3]応答の処理にほとんど時間がかからない場合、攻撃者は検索結果が返されなかったと推測できます。逆に、応答の処理に長い時間がかかる場合、攻撃者は多くの検索結果が返されたと推測します。複数のリクエストを行うことで、攻撃者は被害者のアプリケーションの現在の状態に関する重要な洞察を得ることができ、ユーザーの個人情報を明らかにし、高度なスパムやフィッシング攻撃を仕掛けるのに役立ちます。[17]
歴史
クロスサイトリークは2000年から知られていました。[18]その年にパデュー大学が発表した研究論文には、HTTPキャッシュを使用してユーザーの閲覧習慣のプライバシーを侵害する理論的な攻撃が説明されています。[19] 2007年、スタンフォード大学のアンドリュー・ボルツとダン・ボネは、タイミング情報を使用してクロスサイト応答のサイズを決定する攻撃の詳細を説明したホワイトペーパーを発表しました。[20] 2015年、バーイラン大学の研究者は、同様のリーク方法を使用したクロスサイト検索攻撃について説明しました。この攻撃では、入力を巧妙に加工して応答のサイズを大きくし、応答の生成にかかる時間を比例して増やして、攻撃の精度を高める手法が採用されていました。[21]
独立したセキュリティ研究者は、実際のアプリケーションに対するクロスサイトリーク攻撃について説明するブログ記事を公開しています。2009年、Chris Evansは、悪意のあるサイトがユーザーの受信トレイから機密情報を検索できるYahoo!メールへの攻撃について説明しました。[22] 2018年、Luan Herraraは、 Chromium、Angle、Skia Graphics Engineなどのプロジェクトで使用されているGoogleのMonorailバグトラッカーにクロスサイトリークの脆弱性を発見しました。このエクスプロイトにより、Herraraはバグトラッカーの検索エンドポイントを悪用して、機密性の高いセキュリティ問題に関するデータを盗み出すことができました。[23] [24] 2019年、ポーランドのセキュリティ研究者Terjanqは、有名なGoogle製品間で機密性の高いユーザー情報を盗み出すことができるクロスサイト検索攻撃について説明するブログ記事を公開しました。[25] [26]
Googleは、長年使用されているウェブプラットフォーム機能の悪用に依存するセキュリティ問題への対処に重点を置く一環として、2020年にXSLeaks Wikiを立ち上げました。この取り組みは、悪用されているウェブプラットフォーム機能に関するオープンナレッジデータベースを作成し、クロスサイトリーク攻撃に関する情報を分析および収集することを目的としていました。[22] [27] [28]
2020年以降、学術セキュリティコミュニティでは、これらの攻撃の分類の標準化に関心が寄せられています。2020年、Sudhodananらは、クロスサイトリークに関するこれまでの研究を体系的にまとめた最初の研究者の一人となり、漏洩しやすいURLの検出に使用できるBASTA-COSIというツールを開発しました。[28] [29] 2021年、Knittelらは、クロスサイトリークを評価および特徴付けるための新しい形式モデルを提案し、研究者が複数のブラウザに影響を与える新しいリークを発見できるようにしました。[28] [30] 2022年、Van Goethemらは、これらの攻撃に対する現在利用可能な防御策を評価し、既存のモデルを拡張して、ブラウザコンポーネントの状態をモデルの一部として考慮しました。[28] [13] 2023年、Rautenstrauchらが発表した論文クロスサイトリークに関するこれまでの研究を体系化した論文は、IEEEセキュリティとプライバシーシンポジウムで優秀論文賞を受賞した。[31]
脅威モデル
クロスサイト漏洩の脅威モデルは、攻撃者が被害者を少なくとも部分的に攻撃者の管理下にある悪質なウェブサイトに誘導できることに依存しています。攻撃者は、ウェブページを侵害したり、ユーザーをウェブページにフィッシングして任意のコードをロードしたり、安全なウェブページに悪質な広告を表示したりすることでこれを実現します。[32] [33]
クロスサイトリーク攻撃では、攻撃者が攻撃アプリで使用するために、被害者アプリで少なくとも 1 つの状態依存URL を識別する必要があります。被害者アプリの状態に応じて、この URL は少なくとも 2 つの応答を提供する必要があります。たとえば、ターゲット Web サイトにログインしている場合にのみユーザーがアクセスできるコンテンツにリンクするなどして、URL を作成できます。この状態依存 URL を悪意のあるアプリケーションに含めると、ターゲット アプリへのクロスオリジン リクエストが開始されます。[15]リクエストはクロスオリジン リクエストであるため、同一オリジン ポリシーにより、攻撃者は応答の内容を読み取ることができません。ただし、ブラウザ リーク メソッドを使用すると、攻撃者はHTTP ステータス コードなどの応答の特定の識別可能な特性を照会できます。これにより、攻撃者は応答を区別し、被害者アプリの状態を把握できます。[12] [13]
ウェブページ内のURLへのクロスオリジンリクエストを開始するすべての方法は、すべてのブラウザリーク方法と組み合わせることができますが、異なるインクルード方法とブラウザリークの間には依存関係が存在するため、実際には機能しません。一部のブラウザリーク方法では、成功するために特定のインクルード手法が必要です。[34]たとえば、ブラウザリーク方法が要素の幅や高さなどのCSS属性のチェックに依存している場合、インクルード手法では、クロスオリジンリクエストが無効な画像や異なるサイズの画像を返すときに変化する、幅と高さのプロパティを持つHTML要素（画像要素など）を使用する必要があります。[35] [36]
種類
クロスサイトリークは、確立された統一された分類がない非常に多様な攻撃から構成されています。[37]ただし、複数の情報源では、通常、攻撃中に使用されるリーク手法によってこれらの攻撃を分類しています。[34] 2021年現在、研究者はブラウザのコンポーネントを標的とする38を超えるリーク手法を特定しています。[32]新しい手法は通常、 WebプラットフォームAPIの変更により発見されます。APIは、Webサイトがブラウザに特定の情報を照会できるようにするJavaScriptインターフェースです。[39]これらの手法の大部分は、被害者のWebアプリの状態変化を直接検出することを伴いますが、一部の攻撃では、ブラウザ内の共有コンポーネントの変更を悪用して、被害者のWebアプリに関する情報を間接的に収集します。[34][アップデート]
タイミング攻撃
タイミング攻撃は、複数の応答にわたって特定のイベントのタイミングを計る能力に依存しています。[40]これは2007年にスタンフォード大学の研究者によって発見され、最も古いタイプのクロスサイトリーク攻撃の1つとなっています。[20]
当初はHTTPリクエストがレスポンスを解決するのにかかる時間を区別するためだけに使用されていましたが、[20] 2007年以降に行われた研究では、このリーク手法を使用してウェブアプリの状態間の他の差異を検出できることが実証されています。2017年に、Vilaらはタイミング攻撃によって埋め込みコンテキスト間のクロスオリジン実行時間を推測できることを示しました。これは、同時代のブラウザにサイト分離機能がないため可能になりました。これにより、攻撃側のウェブサイトは、被害者のウェブアプリにイベントが送信されたときに実行されるJavaScriptの量の違いによって生じるタイミングの違いを遅くしたり増幅したりできました。[41] [42]
2021年、Knittelらは、パフォーマンスAPI [注4] が応答でリダイレクトの有無を漏らす可能性があることを示しました。これは、リダイレクトが発生したときにユーザーに表示される時間が負になる可能性があるパフォーマンスAPIのバグが原因で可能になりました。Google Chromeはその後このバグを修正しました。[44] 2023年、Snyderらは、タイミング攻撃を使用して、ウェブサイトがグローバルクォータを使い果たすことで共有リソースをブロックできるプールパーティ攻撃を実行できることを示しました。被害者のウェブアプリにこれらの共有リソースを使用するJavaScriptを実行させ、これらの実行にかかった時間を計測することで、研究者はウェブアプリの状態に関する情報を明らかにすることができました。[45]
エラーイベント
エラーイベントは、攻撃者がエラーイベントハンドラを登録し、それを介してイベントをリッスンすることで、複数の応答を区別できるようにする漏洩技術です。その汎用性と幅広い情報を漏洩する能力により、エラーイベントは典型的なクロスサイト漏洩ベクトルと考えられています。[46]
クロスサイトリーク攻撃におけるエラーイベントの最も一般的な使用例の1つは、イベントハンドラーonloadとonerrorイベントハンドラーをHTML要素に添付し、特定のエラーイベントが発生するのを待つことによってHTTPレスポンスを決定することです。エラーイベントがない場合、HTTPエラーが発生しなかったことを示します。対照的に、ハンドラーがonerror特定のエラーイベントでトリガーされた場合、攻撃者はその情報を使用して、HTTPコンテンツタイプ、ステータスコード、およびメディアタイプエラーを区別できます。[47] 2019年に、ダルムシュタット工科大学の研究者は、ユーザーが任意のコンテンツを相互に共有できるDropbox、Google Docs、GitHubなどの人気のあるWebサービスのユーザーに対して、この手法を使用して標的型匿名化解除攻撃を実行できることを示しました。[48] [49]
2019年以降、エラーイベントの機能は拡張されています。2020年にJancらは、フェッチリクエストのリダイレクトモードを に設定することでmanual、ウェブサイトが特定のURLがリダイレクトであるかどうかに関する情報を漏らす可能性があることを示しました。 [50] [42]同じ頃、Jon MasasとLuan Herraraは、URL関連の制限を悪用することで、攻撃者がURLに関するリダイレクト情報を漏らすために使用できるエラーイベントをトリガーできることを示しました。[51] 2021年にKnittelらは、ウェブサイトが読み込むサブリソースが変更されていないか侵害されていないかを確認するために使用されるメカニズムであるサブリソース整合性チェックによって生成されるエラーイベントが、HTTPレスポンスの生のコンテンツを推測し、レスポンスのコンテンツ長を漏らすためにも使用できることを示しました。[52] [53]
キャッシュタイミング攻撃
キャッシュタイミング攻撃は、ウェブプラットフォーム上の共有キャッシュのヒットとミスを推測する能力に依存しています。[54]キャッシュタイミング攻撃の最初の例の1つは、ページへのクロスオリジンリクエストを作成し、リクエストによって読み込まれたリソースが共有HTTPおよびDNSキャッシュに存在するかどうかを調べることでした。この攻撃を説明する論文は、2000年にパデュー大学の研究者によって書かれ、ウェブページに固有のリソースが読み込まれたかどうかを選択的にチェックすることで、ユーザーの閲覧履歴の大部分を漏らす攻撃能力について説明しています。[55] [54] [56]
この攻撃はますます巧妙化しており、他の種類の情報の漏洩も可能となっている。2014年、Jiaらは、この攻撃によって、多国籍ウェブサイト群のローカライズされたドメインの読み込みにかかる時間を測定することで、人物の位置を特定できることを示した。 [54] [57] [58] 2015年、Van Goethemらは、当時新しく導入されたアプリケーションキャッシュを使用して、ウェブサイトがブラウザに、被害者のウェブサイトが送信するキャッシュ指示を無視して上書きするように指示できることを示した。この論文では、ウェブサイトがキャッシュアクセスの時間を計測することで、キャッシュされた応答のサイズに関する情報を取得できることも実証された。[59] [60]
グローバル制限
グローバル制限はプールパーティ攻撃とも呼ばれ、被害者のウェブアプリの状態に直接依存しません。このクロスサイトリークは、2020年にKnittelらによって最初に発見され、2023年にSnyderらによって拡張されました。[45]この攻撃は、グローバルオペレーティングシステムまたはハードウェアの制限を悪用して共有リソースを枯渇させます。[61]悪用される可能性のあるグローバル制限には、登録できる生のソケット接続の数と登録できるサービスワーカーの数が含まれます。攻撃者は、これらのグローバル制限をトリガーするアクティビティを実行し、被害者のウェブサイトが読み込まれていない状態で同じアクティビティを実行した場合のブラウザの動作の違いを比較することで、被害者のウェブサイトの状態を推測できます。[62]これらのタイプの攻撃は通常、タイミングサイドチャネルも必要とするため、タイミング攻撃とも考えられます。[45]
その他のテクニック
2019年、ガレス・ヘイズは、ウェブサイトのURLハッシュを特定の値に設定し、その後現在のウェブページでフォーカスが失われたかどうかを検出することで、攻撃者が被害者のウェブサイト上の要素の存在と位置を判断できることを発見しました。 [63] 2020年、クニッテルらは、ウェブサイトをフレーミングするか、被害者のウェブサイトのポップアップを作成することで、攻撃者が被害者のウェブサイトのオブジェクトCross-Origin-Opener-Policyへの参照を取得し、ヘッダーが設定されているかwindowどうかを漏らすことができることを示しました。ウィンドウ参照を取得する同じ手法を使用して、攻撃者はプロパティを通じて被害者のウェブサイトのフレーム数をカウントすることもできますwindow.length。[44] [64]
新しい手法が発見され続けている一方で、クロスサイトリークを実行するための古い手法は、ワールドワイドウェブコンソーシアム（W3C）の仕様変更やブラウザのアップデートにより時代遅れになっている。2020年12月、AppleはブラウザSafariのインテリジェントトラッキング防止（ITP）メカニズムを更新し、Googleの研究者が発見したさまざまなクロスサイトリーク手法が無効になった。[65] [66] [67]同様に、2020年にすべての主要ブラウザでキャッシュパーティショニングが広く導入されたことで、キャッシュタイミング攻撃の有効性が低下した。[68]
例
次のJinjaテンプレートを使用して実装された検索エンドポイントインターフェースを備えたPythonベースのWebアプリケーションの例は、クロスサイトリーク攻撃が発生する可能性のある一般的なシナリオを示しています。[36]
< html lang = "en" >
<本文>
< h2 >検索結果</ h2 >
{% は results 内の result です %}
< div クラス= "結果" >
<画像 src = "//cdn.com/result-icon.png" />
{% 結果.説明 %}
</div>
{% endfor %}
</本文>
</html>
このコードは、ウェブページに検索結果を表示するためのテンプレートです。HTTPサーバー バックエンドから提供される結果のコレクションをループし、各結果をその説明とともに、別のウェブサイトから読み込まれたアイコンの横に構造化された div 要素内に表示します。基盤となるアプリケーションは、リクエストに添付されたCookieに基づいてユーザーを認証し、GET パラメータで提供される文字列を使用してユーザーの個人情報のテキスト検索を実行します。返されるすべての結果に対して、コンテンツ配信ネットワーク(CDN) から読み込まれたアイコンが結果の横に表示されます。[32] [69]
この単純な機能は、次のJavaScriptスニペットに示されているように、クロスリーク攻撃に対して脆弱です。 [32]
icon_url = 'https://cdn.com/result-icon.png'とします。
iframe . src = 'https://service.com/?q=password' ;
iframe .onload = async ( ) => {
const start =パフォーマンス. now ();
フェッチを待機します( icon_url );
const期間=パフォーマンス. now () -開始;
if ( duration < 5 ) // キャッシュからリソースをロード
console . log ( 'クエリに結果がありました' );
それ以外
console . log ( 'クエリパラメータに結果がありません' );
};
この JavaScript スニペットは、攻撃者が制御する Web アプリに埋め込むことができ、iframe 内に被害者の Web アプリを読み込み、ドキュメントが読み込まれるのを待ってから CDN からアイコンを要求します。攻撃者はアイコンが返されるタイミングを計ることで、アイコンがキャッシュされているかどうかを判断できます。アイコンは被害者のアプリが少なくとも 1 つの結果を返した場合にのみキャッシュされるため、攻撃者は被害者のアプリが特定のクエリに対して結果を返したかどうかを判断できます。[36] [69] [26]
防御
2017年以前は、ウェブサイトは、すべてのアプリケーション状態に対して同じ応答が返されるようにすることで、クロスサイトリークを防御し、攻撃者がリクエストを区別する能力を阻止することができました。このアプローチは、重要なウェブサイトでは実行不可能でした。2番目のアプローチは、ユーザーのセッション外では機能しないセッション固有のURLを作成することでした。このアプローチはリンクの共有を制限し、非実用的でした。[18] [70]
現代の防御策のほとんどは、HTTPプロトコルの拡張であり、状態の変更を防止したり、クロスオリジンリクエストをステートレスにしたり、複数のオリジン間で共有されるリソースを完全に分離したりします。[68]
共有リソースの分離
キャッシュされた応答
キャッシュされていない応答
クロスサイトリークを実行する最も初期の方法の 1 つは、HTTP キャッシュを使用することです。これは、被害者の Web サイトが読み込んだ可能性のある固有のリソースをブラウザー キャッシュに照会するアプローチです。クロスオリジン リクエストが攻撃 Web サイトを解決するのにかかる時間を測定することで、リソースがキャッシュされているかどうか、またキャッシュされている場合は被害者のアプリの状態を判断できます。[69] [72] 2020 年 10 月現在[アップデート]、ほとんどのブラウザーは HTTP キャッシュ パーティショニングを実装しており、このアプローチの有効性は大幅に低下しています。[73] HTTP キャッシュ パーティショニングは、どの Web サイトがリソースを要求したかに応じて、キャッシュされた各リクエストに複数のキーを設定することで機能します。つまり、Web サイトがリソースを読み込んでキャッシュすると、キャッシュされたリクエストは、リソースの URL と要求元の Web サイトの URL から生成された固有のキーにリンクされます。別の Web サイトが同じリソースにアクセスしようとすると、その Web サイトが以前に同一のリクエストをキャッシュしていない限り、そのリクエストはキャッシュ ミスとして扱われます。これにより、攻撃 Web サイトは、リソースが被害者の Web サイトによってキャッシュされているかどうかを推測できなくなります。[74] [75] [76]
実行コンテキストの分離を可能にするもう1つの開発者向けの機能には、Cross-Origin-Opener-Policy(COOP)ヘッダーがあります。これはもともとブラウザのSpectre問題に対処するために追加されました。 [77] [78]このヘッダーがsame-originレスポンスの一部としてディレクティブで設定されている場合、ブラウザはサードパーティのページから開かれたときにクロスオリジンのウェブサイトが防御側のウェブサイトへの参照を保持できないようにするため、クロスサイトリークの防止に有効であることが証明されています。[79] [80] [81]
サイト間の漏洩を軽減するための取り組みの一環として、すべての主要ブラウザの開発者はストレージパーティショニングを実装し、[82]各ウェブサイトが使用するすべての共有リソースを複数のキーで使用できるようにすることで、ウェブアプリの状態を推測できるインクルード手法の数を大幅に削減しました。[83]
状態変化の防止
クロスサイトリーク攻撃は、悪意のあるウェブページが被害者のアプリケーションからクロスオリジン応答を受信できるかどうかに依存します。悪意のあるアプリケーションがクロスオリジン応答を受信できないようにすることで、ユーザーは状態変更が漏洩する危険にさらされなくなります。[84]このアプローチは、非推奨ヘッダーやコンテンツセキュリティポリシーX-Frame-Optionsヘッダーの新しいframe-ancestorsディレクティブなどの防御に見られ、被害者のアプリケーションは、どのウェブサイトが埋め込みフレームとしてそれを含めることができるかを指定できます。[85]被害者のアプリが信頼できないコンテキストへのウェブサイトの埋め込みを許可しない場合、悪意のあるアプリは、埋め込みフレーム技術を使用して被害者のアプリに対して行われたクロスオリジン要求への応答を監視できなくなります。[86] [87]
同様のアプローチは、クロスオリジンリソースブロッキング（CORB）メカニズムとCross-Origin-Resource-Policy（CORP）ヘッダーによって採用されており、クロスオリジンリクエストは成功しますが、期待されたコンテンツタイプと受信されたコンテンツタイプが一致しない場合は、サードパーティのWebサイトでのコンテンツの読み込みをブロックします。[88]この機能は、もともとSpectre脆弱性に対する一連の緩和策の一部として導入されましたが[89]、悪意のあるWebページが応答を受信して状態の変更を推測するのをブロックするため、クロスオリジンリークの防止に有効であることが証明されています。[86] [90] [91]
クロスオリジンリクエストをステートレスにする
クロスサイト漏洩を緩和する最も効果的なアプローチの 1 つは、クッキーSameSiteの パラメータを使用することです。またはに設定すると、このパラメータにより、ブラウザはほとんどのサードパーティ リクエストでクッキーを送信できなくなり、リクエストは事実上ステートレスになります。[注 5] [91]ただし、認証プロバイダなど、多くの特殊な Web サーバーの動作方法を変更する必要があるため、クッキーの採用は遅れています。 [93] 2020 年に、Chrome ブラウザのメーカーは、すべてのプラットフォームでクッキーをデフォルトの状態としてオンにすると発表しました。 [94] [95]それにもかかわらず、クロスオリジン サイトがリクエストでクッキーを使用できるのは、ページをナビゲート中にリクエストが送信され、クッキーが設定されてから 2 分以内の場合のみである Chromeの緩和策など、クッキーが尊重されないケースがまだあります。 [92]これにより、クロスサイト漏洩が発生する可能性がある制限のバイパスと回避策が生まれました。 [96] [97]LaxStrictSame-SiteSameSite=LaxSameSite=LaxLAX+POSTSameSite=LaxSameSite=Lax
フェッチメタデータヘッダーにはSec-Fetch-Site、、、ヘッダーが含まれており、それぞれリクエストを開始したドメイン、リクエストの開始に関する詳細、防御側のウェブサーバーへのリクエストの送信先に関する情報を提供し、クロスサイトリーク攻撃を軽減するためにも使用されています。Sec-Fetch-Mode[ 98]これらのヘッダーにより、ウェブサーバーは正当なサードパーティの同一サイトリクエストと有害なクロスオリジンリクエストを区別できます。これらのリクエストを区別することで、サーバーは悪意のあるサードパーティのリクエストにはステートレス応答を送信し、通常の同一サイトリクエストにはステートフル応答を送信できます。[99]これらのヘッダーの悪用を防ぐため、ウェブアプリはこれらのヘッダーを設定することを許可されておらず、ブラウザーのみが設定する必要があります。[100] [75]Sec-Fetch-UserSec-Fetch-Dest
参照
参考文献
注記
- ^ WebブラウザとWebサーバー間のやりとりには他の方法（ WebRTCプロトコルなど）もありますが、クロスサイトリークの文脈では、HTTPやりとりとWebSocket接続のみが重要であると考えられています。[1]この記事の残りの部分では、HTTPやりとりとWebSocket接続が、WebブラウザがWebサーバーとやりとりする唯一の2つの方法であると仮定します。
- ^ これには、ステータスコードやHTTPヘッダーなどのレスポンスに関連付けられたメタデータが含まれます[16]
- ^ このようなクエリの例としては、よく知られている銀行の名前や、ユーザーがやり取りしたと思われる人物や組織の連絡先情報などが挙げられます。[17]
- ^パフォーマンスAPIは、Webサイトが Webパフォーマンスに関連するさまざまな指標を取得できるようにするJavaScript関数のセットです[43]
- ^ ディレクティブを設定すると
Strict、すべてのクロスサイトリクエストがステートレスになることが保証されますが、クロスオリジンページから別のページに移動しているときに送信される、Lax状態を変更しない（GETまたは）リクエストに対してはブラウザがクッキーを送信できるようになります。 [92]HEAD
引用
- ^ クニッテルら。 2021、1773、1776 ページ。
- ^ 「Web の仕組み – Web 開発を学ぶ | MDN」。MDN Web Docs 2023 年 7 月 24 日。2023 年 9 月 24 日時点のオリジナルよりアーカイブ。2023年10 月 1 日に閲覧。
- ^ Wagner, David; Weaver, Nicholas; Kao, Peyrin; Shakir, Fuzail; Law, Andrew; Ngai, Nicholas. 「Cookies and Session Management」.カリフォルニア大学バークレー校CS-161 コンピューターセキュリティ教科書. 2024年3月24日閲覧。
- ^ Sudhodanan、Khodayari & Caballero 2020、2–3 ページ。
- ^ ザレフスキー 2011、15ページ。
- ^ シュヴェンク、ニーミエッツ、マインカ 2017、p. 713.
- ^ ザレフスキー 2011、16ページ。
- ^ ソメ2018、13-14頁。
- ^ 「同一生成元ポリシー - ウェブ上のセキュリティ | MDN」。MDN Web Docs 2023年12月20日。 2024年3月24日閲覧。
- ^ クニッテルら。 2021年、p. 1774年。
- ^ ヴァン・ゲーセムら。 2021年、p. 1.
- ^ abc Rautenstrauch、Pellegrino＆Stock 2023、p.2747。
- ^ abcd ヴァン・ゲーセムら。 2022、p. 787。
- ^ ab Gelernter & Herzberg 2015、pp. 1399–1402。
- ^ abc スドーダナン、コダヤリ & カバレロ 2020、p. 1.
- ^ ab ヴァン・ゲーセムら。 2016、p. 448.
- ^ ab Gelernter & Herzberg 2015、p. 1400。
- ^ ab Rautenstrauch、Pellegrino & Stock 2023、p. 2754。
- ^ フェルテン&シュナイダー、2000年、25、26、27、31ページ。
- ^ abc ボルツ & ボーン 2007、623–625 ページ。
- ^ Gelernter & Herzberg 2015、pp. 1394–1397。
- ^ ab Walker, James (2019年3月21日). 「新たなXSリーク技術がユーザー情報を漏洩する新たな方法を明らかにする」The Daily Swig。2023年10月29日時点のオリジナルよりアーカイブ。 2023年10月29日閲覧。
- ^ ヴァン・ゲーセムら。 2021 年、1、6 ページ。
- ^ Herrera, Luan (2019年3月31日). 「XS-Googleのバグトラッカーを検索して脆弱なソースコードを見つける」. Medium . 2023年10月29日時点のオリジナルよりアーカイブ。 2023年10月29日閲覧。
- ^ クニッテルら。 2021年、p. 1772年。
- ^ ab Terjanq. 「Mass XS-Search using Cache Attack – HackMD」。GitHub。2023年10月29日時点のオリジナルよりアーカイブ。2023年10月29日閲覧。
- ^ ヴァン・ゲーセムら。 2021年、p. 10.
- ^ abcd Rautenstrauch、Pellegrino＆Stock 2023、p.2756。
- ^ Sudhodanan、Khodayari & Caballero 2020、p. 2.
- ^ クニッテルら。 2021年、p. 1773年。
- ^ “IEEE Symposium on Security and Privacy 2023”. sp2023.ieee-security.org . 2023年10月29日時点のオリジナルよりアーカイブ。2023年10月29日閲覧。
- ^ abcd ヴァン・ゲーセムら。 2022、p. 786。
- ^ Sudhodanan、Khodayari & Caballero 2020、p. 11.
- ^ abc ヴァン・ゲーセムら。 2022、p. 788。
- ^ ラウテンシュトラウフ、ペレグリーノ＆ストック2023、2745ページ。
- ^ abc ヴァン・ゲーセムら。 2022、p. 785。
- ^ ヴァン・ゲーセムら。 2022、p. 784。
- ^ ラウテンシュトラウフ、ペレグリーノ＆ストック2023、p.2748。
- ^ Rautenstrauch、Pellegrino & Stock 2023、pp. 2755–2756。
- ^ ヴァン・ゲーセムら。 2022、796、797ページ。
- ^ ヴィラ & コップフ 2017、851–853 ページ。
- ^ ab ヴァン・ゲーセムら。 2022、p. 796.
- ^ 「パフォーマンス - Web API | MDN」。MDN Web Docs。2023年2月19日。 2024年3月11日閲覧。
- ^ ab Knittelら。 2021年、p. 1778年。
- ^ abc スナイダー他2023年、7095頁。
- ^ クニッテルら。 2021年、p. 1775年。
- ^ クニッテルら。 2021、1775、1785ページ。
- ^ Staicu & Pradel 2019、924、930ページ。
- ^ ザヘリ、オーレン、クルトモーラ 2022、p. 1505年。
- ^ クニッテルら。 2021年、p. 1785年。
- ^ クニッテルら。 2021、1777、1785ページ。
- ^ クニッテルら。 2021、1778、1782ページ。
- ^ ヴァン・ゲーセムら。 2022、p. 789。
- ^ abc Mishra et al. 2021、p.404。
- ^ フェルテン&シュナイダー、2000年、25、28、29ページ。
- ^ バンサル、プレイブッシュ、ミリック＝フライリング 2015、p. 97.
- ^ Jia et al. 2015、1、2頁。
- ^ バンサル、プレイブッシュ、ミリック＝フライリング 2015、p. 99.
- ^ Van Goethem、Joosen & Nikiforakis 2015、1385、1386 ページ。
- ^ キム、リー、キム 2016、411–413 ページ。
- ^ スナイダーら。 2023、7096、7097ページ。
- ^ クニッテルら。 2021、1782、1776–1778 ページ。
- ^ 「XS-Leak: focus を使用した ID の漏洩」 。PortSwigger Research。2019年 10 月 8 日。2023 年 12 月 28 日時点のオリジナルよりアーカイブ。2023年12 月 28 日閲覧。
- ^ ヴァン・ゲーセムら。 2022、p. 797。
- ^ アルフレッド・ン。「グーグル、アップルのSafariの追跡防止機能が実は追跡を有効にしていたと判明」CNET。2023年12月11日時点のオリジナルよりアーカイブ。2023年12月28日閲覧。
- ^ Wilander, John (2019年12月10日). 「トラッキング防止トラッキング防止」WebKit . 2023年11月16日時点のオリジナルよりアーカイブ。2023年12月28日閲覧。
- ^ Janc, Artur; Kotowicz, Krzysztof; Weichselbaum, Lukas; Clapis, Roberto. 「Safari のインテリジェント トラッキング防止による情報漏洩」。Googleリサーチ。2023 年 12 月 28 日時点のオリジナルよりアーカイブ。2023 年12 月 28 日閲覧。
- ^ ab Knittelら。 2021年、p. 1780年。
- ^ abc フェルテン & シュナイダー 2000、p. 26.
- ^ ザヘリ＆カートモラ2021、160頁。
- ^ フェルテン&シュナイダー、2000年、27、28、29ページ。
- ^ ミシュラら2021年399頁。
- ^ Doan et al. 2022.
- ^ 北村英二 (2020年10月6日). 「キャッシュを分割してセキュリティとプライバシーを強化する」. Chrome for Developers . 2023年10月29日時点のオリジナルよりアーカイブ。2023年10月29日閲覧。
- ^ ab ヴァン・ゲーセムら。 2021年、p. 7.
- ^ Bannister, Adam (2020年10月13日). 「Google ChromeがブラウザのHTTPキャッシュを分割し、XSリーク攻撃を防御」The Daily Swig。2023年10月29日時点のオリジナルよりアーカイブ。 2023年10月29日閲覧。
- ^ レイス、モシュチュク、オスコフ、2019 年、p. 1674年。
- ^ ヴァン ゲーテム、サンチェス-ローラ & ヨーセン 2023、p. 379.
- ^ ヴァン・ゲーセムら。 2022、p. 792.
- ^ 「Cross-Origin-Opener-Policy – HTTP | MDN」。MDN Web Docs 2023年4月10日。2023年10月31日時点のオリジナルよりアーカイブ。2023年10月31日閲覧。
- ^ 北村英治. 「COOPとCOEPを使用してWebサイトを「クロスオリジン分離」する | 記事」. web.dev . 2023年10月31日時点のオリジナルよりアーカイブ。2023年10月31日閲覧。
- ^ スナイダーら。 2023、p. 7092。
- ^ 「State Partitioning - Privacy on the Web | MDN」。MDN Web Docs 2023年7月24日。 2024年2月5日閲覧。
- ^ ヴァン・ゲーセムら。 2022、p. 791.
- ^ カルザバラら。 2020、684、685ページ。
- ^ ab ヴァン・ゲーセムら。 2021年、p. 5.
- ^ 「X-Frame-Options – HTTP | MDN」。MDN Web Docs 2023年7月25日。2023年10月27日時点のオリジナルよりアーカイブ。 2023年10月29日閲覧。
- ^ 「Cross-Origin Read Blocking (CORB)」。Chromium Gerrit。2023年11月7日時点のオリジナルよりアーカイブ。 2023年11月7日閲覧。
- ^ レイス、モシュチュク、オスコフ、2019 年、1665、1666 ページ。
- ^ 「Cross-Origin Resource Policy (CORP) – HTTP | MDN」。MDN Web Docs 2023年5月10日。2023年10月29日時点のオリジナルよりアーカイブ。2023年10月29日閲覧。
- ^ ab Knittelら。 2021年、p. 1781年。
- ^ ab Khodayari & Pellegrino 2022、p. 1592年。
- ^ Khodayari & Pellegrino 2022、p. 1590年。
- ^ Khodayari & Pellegrino 2022、1596、1600ページ。
- ^ コンパーニャら。 2021 年、50–51 ページ。
- ^ 「SameSite の Cookie 制限の回避 | Web Security Academy」 。Portswigger Research。2023年 10 月 29 日時点のオリジナルよりアーカイブ。2023年10 月 29 日閲覧。
- ^ Khodayari & Pellegrino 2022、pp. 1596–1598。
- ^ Weichselbaum, Lukas. 「Fetch Metadata で Web 攻撃からリソースを保護する | Articles」。web.dev。2023年11 月 7 日時点のオリジナルよりアーカイブ。2023 年11 月 7 日閲覧。
- ^ ビールら2021年。
- ^ “Sec-Fetch-Site – HTTP | MDN”. MDN Web Docs . 2023年10月25日. 2023年10月29日時点のオリジナルよりアーカイブ。2023年10月29日閲覧。
出典
- Bansal, Chetan; Preibusch, Sören; Milic-Frayling, Natasa (2015)。「キャッシュタイミング攻撃の再考: 効率的で反復可能なブラウザ履歴、OS、ネットワークスニッフィング」。Federrath, Hannes、Gollmann, Dieter (編)。ICTシステムのセキュリティとプライバシー保護。IFIP 情報通信技術の進歩。第 455 巻。Springer International Publishing。pp. 97–111。doi : 10.1007 / 978-3-319-18467-8_7。ISBN 978-3-319-18467-8.S2CID 8676881 .
- Beer, Philip; Veronese, Lorenzo; Squarcina, Marco; Lindorfer, Martina (2021年9月6日). Webアプリケーションとモバイルプラットフォーム間の橋渡しはまだ途切れている(PDF) . 2023 IEEE 8th European Symposium on Security and Privacy (EuroS&P), SecWeb Workshop Proceedings. 2023年11月7日時点のオリジナルよりアーカイブ(PDF) . 2023年11月7日閲覧。
Fetch Metadata HTTPリクエストヘッダー[45]は、HTTPリクエストのコンテキストをサーバーに提供するHTTPヘッダーのセットです。サーバーはコンテキストを使用して、リクエストが悪意のあるものか、許可すべきかを判断できます。
- Bortz, Andrew; Boneh, Dan (2007 年 5 月 8 日)。「Web アプリケーションのタイミングによる個人情報の漏洩」。第16 回 World Wide Web 国際会議の議事録。WWW '07。Association for Computing Machinery。pp. 621–628。doi : 10.1145 /1242572.1242656。ISBN 978-1-59593-654-7.S2CID 7399871 .
- Calzavara, Stefano; Roth, Sebastian; Rabitti, Alvise; Backes, Michael; Stock, Ben (2020)。「2つのヘッダーの物語: Web 上の一貫性のない {クリックジャッキング} 保護の形式分析」SEC'20: 第 29 回 USENIX セキュリティ カンファレンス シンポジウムの議事録: 683–697。ISBN 978-1-939133-17-5.S2CID 214631428 .
- Compagna, Luca; Jonker, Hugo; Krochewski, Johannes; Krumnow, Benjamin; Sahin, Merve (2021 年 9 月 1 日)。「CSRF 防御としての SameSite クッキーの採用と有効性に関する予備調査」。2021 IEEE 欧州セキュリティおよびプライバシー ワークショップ シンポジウム (EuroS&PW)。IEEE。pp. 49–59。doi : 10.1109 / EuroSPW54576.2021.00012。ISBN 978-1-6654-1012-0. S2CID 240156960。
- Doan, Trinh Viet; van Rijswijk-Deij, Roland; Hohlfeld, Oliver; Bajpai, Vaibhav (2022年2月12日). 「Webの統合に関する実証的見解」. ACM Transactions on Internet Technology . 22 (3): 70:1–70:30. doi :10.1145/3503158. ISSN 1533-5399. S2CID 246803043 .
最近のブラウザ実装[69, 113]では、HTTPキャッシュパーティショニングによってこの問題に対処していますが、この修正により、異なるコンテキストで要求された場合にキャッシュされたリソースが再フェッチされるため、トラフィック量が増加し、読み込み時間が長くなります。
- Somé, Dolière Francis (2018 年 10 月 29 日)。Web アプリケーションのセキュリティとプライバシー (博士論文)。コート ダジュール大学。
- Felten, Edward W.; Schneider, Michael A. (2000 年 11 月 1 日)。「Web プライバシーに対するタイミング攻撃」。第7 回 ACM コンピュータおよび通信セキュリティ会議の議事録。Association for Computing Machinery。pp. 25–32。doi : 10.1145/ 352600.352606。ISBN 978-1-58113-203-8. S2CID 456809。
- Gelernter, Nethanel; Herzberg, Amir (2015 年 10 月 12 日)。 「クロスサイト検索攻撃」。第 22 回 ACM SIGSAC コンピュータおよび通信セキュリティ会議の議事録。CCS '15。Association for Computing Machinery。pp. 1394–1405。doi :10.1145/ 2810103.2813688。ISBN 978-1-4503-3832-5.S2CID 14924784 .
- Jia, Yaoqi; Dong, Xinshu; Liang , Zhenkai; Saxena, Prateek (2015 年 1 月 1 日)。「私はあなたがどこにいたか知っています: ブラウザ キャッシュ経由の地理情報推論攻撃」。IEEEインターネット コンピューティング。19 ( 1 ): 44–53。doi : 10.1109 /MIC.2014.103。ISSN 1089-7801。S2CID 16087472 。
- Khodayari, Soheil; Pellegrino, Giancarlo (2022)。「SameSite の現状: SameSite クッキーの使用、有効性、妥当性の調査」。2022 IEEEセキュリティとプライバシーに関するシンポジウム (SP)。IEEE。pp. 1590–1607。doi : 10.1109 / SP46214.2022.9833637。ISBN 978-1-6654-1316-9.S2CID 251140677 .
- Kim, Hyungsub、Lee, Sangho、Kim, Jong (2016 年 12 月 5 日)。「ストレージ使用量のリモート監視によるブラウザのアクティビティとステータスの推測」。第32 回コンピュータ セキュリティ アプリケーション年次会議の議事録。ACSAC '16。Association for Computing Machinery。pp. 410–421。doi :10.1145 / 2991079.2991080。ISBN 978-1-4503-4771-6. S2CID 10483542 – アリゾナ州立大学図書館経由。
- Knittel, Lukas; Mainka, Christian; Niemietz, Marcus; Noß, Dominik Trevor; Schwenk, Jörg (2021 年 11 月 12 日)。「XSinator.com: 形式モデルから Web ブラウザーでのクロスサイト漏洩の自動評価まで」。2021 ACM SIGSACコンピューターおよび通信セキュリティ会議の議事録。Association for Computing Machinery。pp. 1771–1788。doi : 10.1145/ 3460120.3484739。ISBN 978-1-4503-8454-4. S2CID 244077807。
- Mishra, Vikas; Laperdrix, Pierre; Rudametkin, Walter; Rouvoy, Romain (2021). 「Déjà vu: ブラウザキャッシュヘッダーを悪用してオンラインユーザーを識別および追跡する」。Proceedings on Privacy Enhancing Technologies . 2021 (2): 391–406. doi : 10.2478/popets-2021-0033 . hdl : 20.500.12210/57495 . ISSN 2299-0984. S2CID 231779262. 2023年10月29日時点のオリジナルよりアーカイブ。 2023年10月29日閲覧。
- Rautenstrauch, Jannis; Pellegrino, Giancarlo; Stock, Ben (2023 年 5 月 21 日)。「The Leaky Web: ブラウザーと Web におけるクロスサイト情報漏洩の自動検出」。2023 IEEEセキュリティとプライバシーに関するシンポジウム (SP)。IEEE。pp. 2744–2760。doi :10.1109/ SP46215.2023.10179311。ISBN 978-1-6654-9336-9S2CID 259321089 – CISPA 経由 – ヘルムホルツ情報セキュリティ センター出版物データベース。
- Reis, Charles; Moshchuk, Alexander; Oskov, Nasko (2019)。「サイト分離: ブラウザ内での Web サイトのプロセス分離」。SEC'19 : 第 28 回 USENIX セキュリティ カンファレンス シンポジウム議事録。USENIX 協会。pp. 1661–1678。ISBN 978-1-939133-06-9. S2CID 199522067 . 2023年11月7日時点のオリジナルよりアーカイブ。2023年11月7日閲覧。
- シュウェンク、ヨルク。ニーミエッツ、マーカス。クリスチャン・メインカ（2017）。 {Same-Origin} ポリシー: 最新のブラウザーでの評価。 USENIX協会。 713–727ページ。ISBN 978-1-931971-40-9.S2CID 9641053 .
- Snyder, Peter; Karami, Soroush; Edelstein, Arthur; Livshits, Benjamin; Haddadi, Hamed (2023 年 10 月 26 日)。「プール パーティ: Web トラッキングのためのブラウザー リソース プールの悪用」。第32 回 USENIX セキュリティ カンファレンス シンポジウムの議事録。SEC '23。USENIX 協会: 7091–7105。ISBN 978-1-939133-37-3。
- Staicu, Cristian-Alexandru; Pradel, Michael (2019)。「漏洩画像: Web における標的型プライバシー攻撃」。第 28 回 USENIX セキュリティ シンポジウム会議議事録。SEC '19: 923–939。ISBN 978-1-939133-06-9.S2CID 156052170 .
- Sudhodanan, Avinash; Khodayari, Soheil; Caballero, Juan (2020)。「クロスオリジン状態推論 (COSI) 攻撃: XS リークによる Web サイト状態の漏洩」。2020年ネットワークおよび分散システム セキュリティ シンポジウムの議事録。インターネット協会。doi : 10.14722 / ndss.2020.24278。ISBN 978-1-891562-61-7. S2CID 199452779。
- Van Goethem, Tom; Franken, Gertjan; Sanchez-Rola, Iskander; Dworken, David; Joosen, Wouter (2021 年 9 月 6 日)。クロスサイト漏洩と防御の理解(PDF)。2023 IEEE 8th European Symposium on Security and Privacy (EuroS&P)、SecWeb Workshop Proceedings。p. 1。2023年 10 月 11 日時点のオリジナルよりアーカイブ(PDF) 。2023 年10 月 11 日に閲覧。
- Van Goethem, Tom; Franken, Gertjan; Sanchez-Rola, Iskander; Dworken, David; Joosen, Wouter (2022 年 5 月 30 日)。「SoK: 拡張形式モデルによる XS リークに関する現在および将来の研究方向の調査」。2022 ACM on Asia Conference on Computer and Communications Security の議事録。Association for Computing Machinery。pp. 784–798。doi : 10.1145 / 3488932.3517416。ISBN 978-1-4503-9140-5. S2CID 248990284。 この記事には、Tom Van Goethem、Gertjan Franken、Iskander Sanchez-Rola、David Dworken、Wouter Joosen によるテキストが組み込まれており、CC BY 4.0 ライセンスの下で利用可能です。
- Van Goethem, Tom; Sanchez-Rola, Iskander; Joosen, Wouter (2023)。「スクリプト化されたヘンチマン: クロスサイト脆弱性検出のための XS リークの活用」。2023 IEEE セキュリティおよびプライバシー ワークショップ (SPW)。IEEE。pp. 371–383。doi :10.1109 / SPW59333.2023.00038。ISBN 979-8-3503-1236-2. S2CID 259267534 . 2023年11月7日閲覧。
- ヴァン・ゲーセム、トム。ヴァンホーフ、マシー。ピーセンス、フランク。ヨーセン、ウーター (2016)。リクエストと征服: {Cross-Origin} リソース サイズの公開。 447–462ページ。ISBN 978-1-931971-32-4。
- Van Goethem, Tom; Joosen, Wouter; Nikiforakis, Nick (2015 年 10 月 12 日)。「時計はまだ刻々と進んでいます: 現代の Web におけるタイミング攻撃」。第 22 回 ACM SIGSAC コンピュータおよび通信セキュリティ会議の議事録。CCS '15。Association for Computing Machinery。pp. 1382–1393。doi :10.1145 / 2810103.2813632。ISBN 978-1-4503-3832-5.S2CID 17705638 .
- Vila, Pepe; Köpf, Boris ( 2017)。「Loophole: Chrome の共有イベント ループに対するタイミング攻撃」。SEC'17 :第 26 回 USENIX セキュリティ カンファレンス シンポジウム議事録: 849–864。arXiv : 1702.06764。ISBN 978-1-931971-40-9。
- Zaheri, Mojtaba; Curtmola, Reza (2021). 「Leakuidator: 漏洩リソース攻撃と対策」。 Garcia-Alfaro, Joaquin; Li, Shujun; Poovendran, Radha; Debar, Hervé; Yung, Moti (編)。通信ネットワークにおけるセキュリティとプライバシー。 コンピュータサイエンス、社会情報学、電気通信工学研究所の講義ノート。 第399巻。 Springer International Publishing。 pp. 143–163。doi : 10.1007/978-3-030-90022-9_8。ISBN 978-3-030-90022-9. S2CID 237476137。
- Zaheri, Mojtaba; Oren, Yossi; Curtmola, Reza (2022)。「キャッシュサイドチャネルによる標的型匿名化：攻撃と防御」。第31回USENIXセキュリティシンポジウム会議議事録。SEC '22: 1505–1523。ISBN 978-1-939133-31-1.S2CID 251092191 .
- ザレフスキー、ミハル（2011 年 11 月 15 日）。『The Tangled Web: A Guide to Securing Modern Web Applications』No Starch Press。ISBN 978-1-59327-388-0。
さらに読む
- Knittel, Lukas; Mainka, Christian; Niemietz, Marcus; Noß, Dominik Trevor; Schwenk, Jörg (2021 年 11 月 12 日)。「XSinator.com: 形式モデルから Web ブラウザーでのクロスサイト漏洩の自動評価まで」。2021 ACM SIGSACコンピューターおよび通信セキュリティ会議の議事録。Association for Computing Machinery。pp. 1771–1788。doi : 10.1145/ 3460120.3484739。ISBN 978-1-4503-8454-4. S2CID 244077807。
- Rautenstrauch, Jannis; Pellegrino, Giancarlo; Stock, Ben (2023 年 5 月 21 日)。「The Leaky Web: ブラウザーと Web におけるクロスサイト情報漏洩の自動検出」。2023 IEEEセキュリティとプライバシーに関するシンポジウム (SP)。IEEE。pp. 2744–2760。doi :10.1109/ SP46215.2023.10179311。ISBN 978-1-6654-9336-9S2CID 259321089 – CISPA 経由 – ヘルムホルツ情報セキュリティ センター出版物データベース。
- Van Goethem, Tom; Franken, Gertjan; Sanchez-Rola, Iskander; Dworken, David; Joosen, Wouter (2022 年 5 月 30 日)。「SoK: 拡張形式モデルによる XS リークに関する現在および将来の研究方向の調査」。2022 ACM on Asia Conference on Computer and Communications Security の議事録。Association for Computing Machinery。pp. 784–798。doi : 10.1145 / 3488932.3517416。ISBN 978-1-4503-9140-5. S2CID 248990284。
- Van Goethem, Tom; Franken, Gertjan; Sanchez-Rola, Iskander; Dworken, David; Joosen, Wouter (2021 年 9 月 6 日)。クロスサイト漏洩と防御の理解(PDF)。2023 IEEE 8th European Symposium on Security and Privacy (EuroS&P)、SecWeb Workshop Proceedings。p. 1。2023年 10 月 11 日時点のオリジナルよりアーカイブ(PDF) 。2023 年10 月 11 日に閲覧。
外部リンク
- 「XSLeaks Wiki - はじめに」。xsleaks.dev。
- 「XSinator - XS-Leak ブラウザ テスト スイート」。xsinator.com。