Introduction

XS-Leaks Wiki #

Overview #

Cross-site leaks (別名 XS-Leaks、XSLeaks) は、Web プラットフォームに組み込まれたサイドチャネル 1 に由来する脆弱性分類です。 それらは、Web サイトが相互にやり取りできるようにするという Web のコア原則を利用し、正当なメカニズム 2 を悪用してユーザーに関する情報を推測します。 XS-Leaks の見方として、クロスサイトリクエストフォージェリ (CSRF 3) 技術との類似性を強調する方法があります。XS-Leaksは、他の Web サイトがユーザーに代わってアクションを実行するのではなく、ユーザーに関する情報を推測するために使用されます。

例えばブラウザは、ウェブサイトが、サブリソースをロードしたり、ナビゲートしたり、他のアプリケーションにメッセージを送信することを可能にします。このような動作は、一般的にウェブプラットフォームに組み込まれたセキュリティメカニズム（例えば、[same-origin policy]（https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy））によって制限されますが、XS-Leaksはウェブサイト間の相互作用中に露出する小さな情報の断片を利用します。

XS-Leaksの原理は、ウェブ上で利用可能なこのようなサイドチャネルを利用して、他のウェブアプリケーション内のデータ、ローカル環境の詳細、接続されている内部ネットワークなど、ユーザーの機密情報を明らかにすることです。

Cross-site オラクル #

XS-Leakに使用される情報の断片は、通常バイナリ形式を持ち、「オラクル」と呼ばれます。 オラクルは一般的に、攻撃者から見える形で巧妙に用意された質問に対してYESまたはNOで答えます。

例えば、オラクルは次のように問われることがあります。

他のウェブアプリケーションでユーザーの検索結果にsecretという単語が表示されるか？

これは、という問いかけに等しいかもしれません:

クエリ ?query=secret は HTTP 200 ステータスコードを返すか？

また、Error EventsでHTTP 200のステータスコードを検出することができるため、この問い合わせと同じ効果となります:

アプリケーションで ?query=secret からリソースを読み込むと、onload イベントが発生するか？

上記のクエリーは、攻撃者によって多くの異なるキーワードで繰り返される可能性があり、その結果、ユーザーのデータに関する機密情報を推測するためにレスポンスが使用される可能性があります。

ブラウザは、善意でありながら、少量のクロスオリジン情報を漏らしてしまう可能性のある、さまざまなAPIを幅広く提供しています。 これらのAPIについては、このWikiの中で詳しく説明します。

Example #

ウェブサイトは、他のウェブサイトのデータに直接アクセスすることはできませんが、他のウェブサイトからリソースをロードし、その副作用を観察することは可能です。たとえば、evil.comはbank.comからの応答を明示的に読むことを禁じられていますが、evil.comはbank.comからスクリプトをロードしようと試み、それがうまくロードされたかどうかを判断することができます。

example

例えば、bank.com が、ある種の取引におけるユーザーの領収書に関するデータを返す API エンドポイントを持っているとする。

  1. evil.comは、スクリプトとしてURL bank.com/my_receipt?q=groceriesをロードしようとすることができます。デフォルトでは、ブラウザはリソースをロードする際にクッキーを添付するので、bank.comへのリクエストはユーザーのクレデンシャルを運ぶことになります。
  2. ユーザーが最近食料品を購入した場合、スクリプトは HTTP 200 ステータスコードで正常にロードされます。ユーザーが食料品を購入していない場合、リクエストはHTTP 404*ステータスコードでロードに失敗し、エラーイベントがトリガーされます。
  3. エラーイベントをリスニングし、異なるクエリでこのアプローチを繰り返すことで、攻撃者はユーザーの取引履歴に関するかなりの量の情報を推論することができます。

上記の例では、2つの異なるオリジンのウェブサイト（evil.com と bank.com ）が、ブラウザがウェブサイトの使用を許可している API を介して、相互に作用しています。 この相互作用は、ブラウザやbank.comの脆弱性を悪用するものではありませんでしたが、evil.comがbank.com上のユーザーのデータに関する情報を取得することを可能にしました。  

XS-Leaksの根本的な原因 #

ほとんどのXS-Leaksの根本原因は、ウェブのデザインに内在するものです。多くの場合、アプリケーションは何も間違っていないのに、XS-Leaksによる情報漏洩の危険にさらされています。XS-Leaksの根本的な原因をブラウザレベルで修正することは、多くの場合、既存のウェブサイトを壊してしまうため困難です。このため、ブラウザは様々な防御機構(https://webapppentestguidelines.github.io/xs-leaks/defenses/)を実装し、この困難を克服しています。これらの防御の多くは、通常、特定の HTTP ヘッダ (例: Cross-Origin-Opener-Policy: same-origin) を使うことによって、より厳しいセキュリティモデルを選ぶようウェブサイトに要求していますが、望ましい結果を得るためにはしばしば組み合わせる必要があります。

XS-Leaksの情報源は、以下のように区別することができます：

  1. ブラウザAPI (例： Frame Counting と Timing Attacks)
  2. ブラウザの細かい実装とバグ (例：　Connection Pooling や typeMustMatch)
  3. ハードウェアのバグ(例： Speculative Execution Attacks 4)

ちょっとした歴史 #

XS-Leaksは長い間ウェブプラットフォームの一部でした。ユーザーのウェブ活動に関する情報を漏らすタイミング攻撃は少なくとも 2000年には知られていました。

このクラスの問題は、その影響力を高める新しいテクニックが発見されるにつれて、着実に注目を集めるようになりました5。 2015年、GelernterとHerzbergは「Cross-Site Search Attacks」6を発表し、タイミング攻撃を悪用して、GoogleとMicrosoftが構築したWebアプリケーションに対して影響力の大きいXS-Search攻撃を実装しました。それ以来、さらに多くの XS-Leak テクニックが発見され、テストされています。

近年、ブラウザは様々な新しい防御機構 を実装して、アプリケーションを XS-Leaks からより簡単に保護できるようにしました。

このWikiについて #

この wiki は、読者に XS-Leaks を紹介することと、XS-Leaks を悪用する経験豊富な研究者のためのリファレンス ガイドとして機能することの両方を目的としています。 この wiki にはさまざまな手法に関する情報が含まれていますが、新しい手法は常に出現しています。 新しいテクニックを追加するか、既存のページを拡張するかに関係なく、改善は常に高く評価されます!

このウィキに貢献する方法を見つけて、 Contributions の記事で貢献者のリストを参照してください。

※なお、和訳版についての要望やコミットは別途Issue等にて受け付けます。

本翻訳に関わった組織・翻訳者 #

NPO日本ネットワークセキュリティ協会（JNSA）について #

NPO日本ネットワークセキュリティ協会は、ネットワーク・セキュリティ製品を提供しているベンダー、システムインテグレータ、インターネットプロバイダ等ネットワークセキュリティシステムに携わるベンダーが結集し、ネットワーク社会の情報セキュリティレベルの維持・向上および日本における情報セキュリティ意識の啓発に努めるとともに、最新の情報セキュリティ技術および情報セキュリティへの脅威に関する情報提供等を行うことで、情報化社会へ貢献することを目的としています。

http://www.jnsa.org/

日本セキュリティオペレーション事業者協議会（ISOG-J）について #

日本セキュリティオペレーション事業者協議会（Information Security Operation providers Group Japan 略称: ISOG-J）は、セキュリティオペレーション技術向上、オペレータ人材育成および関係する組織・団体間の連携を推進することによって、セキュリティオペレーションサービスの普及とサービスレベルの向上を促し、安全で安心して利用できるIT環境実現に寄与することを目的として設立されました。

http://isog-j.org/

NewTech WGについて #

本書はISOG-J WG1 の新技術に対する診断手法分科会によって翻訳されました。 本グループでは、比較的新しい技術に関して調査・研究しています。

XSSやSQLインジェクション等の脆弱性はすでに診断ツールが対応しているものの、たとえばGraphQLやWASM等に固有の脆弱性については、まだ各社内で確立されたツールや手法がない技術もあります。 これらの領域に関して、一般的に普及している技術について調査し、必要があればツールそのものを実装することで、診断手法を確立・ドキュメント化します。

分野によっては、こういった領域に関して親和性の高い学生も交えて、産学連携して進める予定です。

翻訳者一覧 (敬称略、順不同) #

  • 三井物産セキュアディレクション株式会社　廣田 一貴
  • 三井物産セキュアディレクション株式会社　山本 健太
  • 三井物産セキュアディレクション株式会社　洲崎 俊
  • 株式会社セキュアスカイ・テクノロジー　岩間 湧
  • LINE株式会社 林義徳

本プロジェクトに関するお問い合わせ先 #

本プロジェクトに関して質問や要望、改善すべき点や感想等ございましたら、本GitHubのIssueにてご連絡いただけますと幸いです。

References #

  1. Side Channel Vulnerabilities on the Web - Detection and Prevention, link ↩︎

  2. In some cases, these features are maintained to preserve backwards compatibility. But, in other cases, new features are added to browsers regardless of the fact that they introduce potential cross-site leaks (e.g. Scroll to Text Fragment), as the benefits are considered to outweigh the downsides. ↩︎

  3. Cross Site Request Forgery (CSRF), link ↩︎

  4. Meltdown and Spectre, link ↩︎

  5. Browser Side Channels, link ↩︎

  6. Cross-Site Search Attacks, link ↩︎