https://webapppentestguidelines.github.io/xs-leaks/category/defense/Recent content in Defense on XS-Leaks WikiHugo -- gohugo.ioja-jpMon, 30 Nov 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/isolation-policies/resource-isolation/Mon, 30 Nov 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/isolation-policies/resource-isolation/Resource Isolation Policyは、外部のWebサイトがリソースを要求するのを防ぎます。このようなトラフィックをブロックすることで、CSRF、XSSI、XS-Leaks などの一般的な Web 脆弱性を軽減できます。このポリシーは、エンドポイントがクロスサイトコンテキストでロードされることを意図していないアプリケーションに対して有効にすることができ、アプリケーションから来るリソース要求だけでなく、直接の遷移も可能にします。 Fetch Metadataを用いた実装 # 以下のコードは、Fetch Metadata ヘッダーを使用したResource Isolation Policyの実装例を示しています: # クロスサイトリクエストを拒否し、クリックジャッキングやXS-Leaks、他のバグから保護します def allow_request(req): # [OPTIONAL] クロスオリジンで提供されることを意図したパス/エンドポイントを除外する。 if req.path in ('/my_CORS_endpoint', '/favicon.png'): return True # `Cross-Origin-Resource-Policy: same-site`を設定すると安全です。(考慮事項参照) # Fetch Metadataを送信しないブラウザからのリクエストを許可する if not req['headers']['sec-fetch-site']: return True # same-siteやブラウザ経由のリクエストの許可 if req['headers']['sec-fetch-site'] in ('same-origin', 'same-site', 'none'): return True # 埋め込みを含むシンプルなトップレベルの遷移を許可する if req['headers']['sec-fetch-mode'] == 'navigate' and req.method == 'GET': return True # その他のリクエストを拒否する return False 考慮事項 # Resource Isolation Policyから明示的に除外されていないすべてのリクエストに Cross-Origin-Resource-Policy: same-site レスポンスヘッダを設定しても問題ないはずです。CORPを参照してください。https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/isolation-policies/framing-isolation/Mon, 30 Nov 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/isolation-policies/framing-isolation/Framing Isolation Policy は、Framing Protections のより厳格なバージョンで、ブラウザではなく、アプリケーションレベルでリクエストがブロックされます。これは、フレーム化を意図していないエンドポイントへのフレーム化リクエストをブロックすることで、さまざまな攻撃（XSSI、CSRF、XS-Leaksなど）から保護するために設計されています。 Resource Isolation Policy と組み合わせることで、XS-Leaksの攻撃対象領域を効果的に絞り込むことができます。 tip フレーム化できないエンドポイントをすべて拒否するのではなく、例えば 信頼できる発信元からこのページを訪問したことを確認する といったアクションを確認するようユーザーに促すことで、バックグラウンドでの攻撃のリスクを軽減し、同時にアプリケーションの意図しない破損を防ぐことができます。 tip Resource Isolation Policy と共に展開された場合、Framing Isolation Policy はウィンドウ参照（例 window.length）を利用したリークから保護しないため、COOP や Navigation Isolation Policy など他の画面遷移保護が役に立つことがあります。 Fetch Metadataを用いた実装 # 以下のコードは、アプリケーションによる Framing Isolation Policy の実装例を示しています。 # CSRF、XSSI、XS-Leaksなどのバグから保護するために、クロスサイトリクエストを拒否します。 def allow_request(req): # Fetch Metadataを送信しないブラウザからのリクエストを許可する。 if not req['headers']['sec-fetch-site']: return True if not req['headers']['sec-fetch-mode']: return True if not req['headers']['sec-fetch-dest']: return True # 遷移以外のリクエストを許可する。 if req['headers']['sec-fetch-mode'] not in ('navigate', 'nested-navigate'): return True # 遷移以外のリクエストを許可する。 if req['headers']['sec-fetch-dest'] not in ('frame', 'iframe', 'embed', 'object'): return True # [OPTIONAL] クロスサイトで提供されることを意図したパス/エンドポイントを除外する。 if req.https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/isolation-policies/navigation-isolation/Mon, 30 Nov 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/isolation-policies/navigation-isolation/Navigation Isolation Policy は、クロスサイトウィンドウコンテキストを利用した CSRFやクリックジャッキング、反射型XSS、XS-Leak を緩和することを目的としたサーバーサイドの保護機構です。これは厳格なポリシーであり、ハイパーリンクを介した遷移を含むすべてのクロスサイトの遷移をブロックするため、アプリケーションを破壊する可能性があります。 tip すべてのクロスサイトインタラクションを拒否する代わりに、ユーザーにアクションを確認するよう促すことができます。例えば、このページを信頼できる発信元から訪れたことを確認することで 、バックグラウンドでの攻撃のリスクを軽減し、同時にアプリケーションの意図しない破壊を防ぐのに役立ちます。 Fetch Metadataを用いた実装 # 以下のコードは、Fetch Metadata ヘッダーを使用した Navigation Isolation Policy の実装例を示しています1: # クロスサイトリクエストを拒否し、クリックジャッキングやXS-Leaks、他のバグから保護します def allow_request(req): # クロスサイトでないリクエストを許可する if req['headers']['sec-fetch-site'] != 'cross-site': return True # ホームページなど、遷移されることを意図したエンドポイントへのリクエストを許可する if req.path in whitelisted_paths: return True # 埋め込みを含むすべてのトップレベルクロスサイトの遷移をブロックする if req['headers']['sec-fetch-mode'] in ('navigate', 'nested-navigate'): return False # その他のリクエストを許可する return True 参考文献 # Fetch Metadata Request Headers playground, link ↩︎https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/isolation-policies/strict-isolation/Mon, 30 Nov 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/isolation-policies/strict-isolation/Strict Isolation Policyは、すべてのクロスサイトインタラクション（ハイパーリンクを介したアプリケーションへの遷移を含む）から保護することを目的としています。これは非常に厳しいポリシーであり、アプリケーションが正常に機能しなくなる可能性があります。 tip すべてのクロスサイトインタラクションを拒否する代わりに、ユーザーにアクションを確認するよう促すことができます。例えば、このページを信頼できる発信元から訪れたことを確認することで 、バックグラウンドでの攻撃のリスクを軽減し、同時にアプリケーションの意図しない破壊を防ぐのに役立ちます。 しかし、他のリソースはバックグラウンドで読み込まれるため、これは遷移のリクエストに対してのみ機能します。 Fetch Metadataを用いた実装 # 以下のコードは、アプリケーションによる Strict Isolation Policy の実装例を示しています: # クロスオリジンリクエストを拒否し、CSRFやXSSI、他のバグから保護します def allow_request(req): # Fetch Metadataを送信しないブラウザからのリクエストを許可する if not req['headers']['sec-fetch-site']: return True # cross-siteリクエストをブロック if req['headers']['sec-fetch-site'] == 'cross-site': return False # その他のリクエストを許可する return True SameSite cookiesを用いた実装 # もしサーバーがSameSite=strictフラグを持つCookieを送ると、このコードで示されるように、そのCokkieを含まないで返される全てのリクエストは拒否されることがあります。 # クロスオリジンリクエストを拒否し、CSRFやXSSI、他のバグから保護します def allow_request(req): if req['cookies']['strict-cookie'] == 'true': return True # strict Cookieを持たないリクエストはブロック return False Refererを用いた実装 # また、Referer ヘッダーを使用して、信頼できない送信元からのリクエストを拒否することも可能です: # 信頼できないリファラーから来たリクエストを拒否する def allow_request(req): # referer ヘッダが信頼できるかどうかを確認する。つまりtrusted_referers ディクショナリに存在するかどうかを確認する。 if req['headers']['referer'] in trusted_referers: return True # strict Cookieを持たないリクエストをブロック return False importanthttps://webapppentestguidelines.github.io/xs-leaks/docs/defenses/opt-in/fetch-metadata/Mon, 30 Nov 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/opt-in/fetch-metadata/Fetch Metadata Request Headers は、ブラウザが HTTPS リクエストで送信するヘッダです。これらのヘッダは、リクエストがどのように発生したかについてのコンテキストを提供し、アプリケーション側がそれに対してどのように応答するかについて、より多くの情報に基づいた決定を行うことができるようにします。これにより、サーバーは潜在的な攻撃（例：予期しないクロスオリジンリクエスト）を検知した際に、異なる動作をすることができます[^1]。これは、サーバーに厳格なポリシーが導入されていれば、XSSI、XS-Leaks、クリックジャッキング、CSRF などのクロスオリジン攻撃に対して非常に効果的です。 XS-Leaksのシナリオでは、サーバーはリクエストがいつクロスオリジン（例：攻撃者のオリジン）で行われたかを知る能力を持ち、ユーザーデータを含まないような別のレスポンスを返すことができます。この種のレスポンスは、ユーザーに関するいかなる情報または状態も提供しないため、攻撃者にとって有用ではなくなります。Fetch Metadataはまた、フレーミングや遷移のリクエストをブロックするために使用することができます。 important セキュリティ上の理由から、Fetch Metadataヘッダは暗号化されたリクエスト（HTTPS）にのみ付与されます。 Fetch Metadata vs. SameSite cookie # Fetch Metadata ヘッダは、SameSite Cookieによって提供される保護を拡張するために使用することができます。Fetch Metadata ヘッダと SameSite Cookieの両方がクロスサイトリクエストを拒否するために使われることがありますが Fetch Metadata は以下のような要素に基づいて、より情報に基づいた決定をすることができます。 リクエストはSame Origin（同一生成元）か、Same Site（同一サイト）か リクエストはどのように開始されたか(例: fetch、スクリプト、トップナビゲーション) リクエストはユーザの操作によって発生したのか リクエストはブラウザによって発生したか（例：オムニボックスに直接URLを入力する） これは、SameSite Cookieがサービスの機能を壊す可能性があるシナリオにおいて、より正確な保護の展開を可能にします。SameSite Cookieと比較した Fetch Metadata の欠点は、前者が暗号化されていないリクエスト(HTTP)も保護できるのに対し、後者がそうできないことです。 考察 # Fetch Metadataヘッダは徹底した防護戦略のための有用なツールですが、 SameSite Cookies, COOP, あるいは Framing Protections といった仕組みの代わりとして見なされるものではありません。たとえFetch Metadataヘッダを使用して同様の結果を得ることができるとしても、サーバに加えてクライアント側でもこれらの制限を実施することが最善です。 Fetch Metadataヘッダの有用性は、アプリケーションの対象範囲とデプロイの正しさに依存します。 ポリシー # Fetch Metadata Request Headers を利用した特定のポリシーについては Resource Isolation Policy と [Framing Isolation Policy](https://webapppentestguidelines.https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/design-protections/cache-protections/Fri, 16 Oct 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/design-protections/cache-protections/cache probingをベースとしたXS-Leakを対策するために、アプリケーションで利用できるさまざまなアプローチがあります。 これらのアプローチについて、以下のセクションで説明します。 Cache-Controlヘッダによるキャッシュ保護 # キャッシングを無効化することが許容できる場合には、cache probing攻撃に対する強力な対策となります。 キャッシュを無効化すると、リソースを読み込むたびに、リソースを再度フェッチする必要があります。 キャッシュを無効化するには、保護したいすべてのレスポンスに Cache-Control：no-storeヘッダを設定します。 メリット： すべての主要なブラウザでサポートされている デメリット: Webサイトのパフォーマンスに悪影響を与える ランダムなトークンによるキャッシュ保護 # キャッシュの無効化ではなく、cache probing攻撃を対策するために、アプリケーションがURLに追加のデータを含める方法もあります。 これは、参照するすべてのサブリソースのURLにランダムなトークンを含めることで実現できます。 攻撃者がこのランダムなトークンを推測できなければ、単純な手法では、攻撃者はキャッシュ内にアイテムがあるかを判断できません。 example アプリケーションのすべてのページにユーザのプロフィール写真 /user /<USERNAME>.png が読み込まれるとします。 攻撃者は /user/john.png , /user/jane.png などのキャッシュを調査することにより、どのユーザがサインインしているかを判定できます。 ここでランダムなトークンが活用できます。 もし実装されていれば、アプリケーションは読み込みのたびに /user/<USERNAME>.png？cache_buster=<RANDOM_TOKEN> からユーザのプロフィール写真を取得します。 サーバは、このランダムなトークンに対して何も行う必要はありません。 これは純粋に、攻撃者がランダムなトークンを知らないためにキャッシュを調査できないことを、実現するためだけのものとなります。 もっと丁寧に実装するのであれば、アプリケーションがページの読み込みに渡って再利用することができるユーザ固有のランダムなトークンを持つこともできます。 これにより、特定のユーザに対してURLが一定に保たれるため、サブリソースをキャッシュすることができます。 メリット： すべての主要なブラウザでサポートされている キャッシングを阻害しない デメリット： 実装が難しい Fetch Metadataによるキャッシュ保護 # Fetch-Metadata は、クライアント側でリクエストが開始された方法と理由をサーバが判断できるようにすることを目的としています。 公開される情報の1つは、リクエストが同じオリジンからのものか、別のオリジンからのものかを指定するSec-Fetch-Site ヘッダです。 Varyヘッダと組み合わせることで、リクエストが同じオリジンから行われたか、異なるオリジンから行われたかに基づいて、ブラウザにキャッシュをセグメント化させることができます。 これは、保護したいすべてのリソースに Vary: Sec-Fetch-Site を設定することで実現できます。 example cache probing 攻撃から保護したいリソースcdn.example.com/image.pngがあると仮定します。 Vary：Sec-Fetch-Siteを設定すると、以下のように動作します。 example.comがリソースを読み込もうとすると、リクエストは同じサイトによって開始されるため、(SFS: same-site, resource_url)にキャッシュされます。 cdn.example.comがリソースを読み込もうとすると、リクエストは同じオリジンによって開始されるため、(SFS: same-origin, resource_url)にキャッシュされます。 evil.comがリソースを読み込もうとすると、リクエストは別のサイトによって開始されるため、(SFS: cross-site, resource_url)にキャッシュされます。 ※Vary：Sec-Fetch-SiteをSFSと省略して記載しています。https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/secure-defaults/corb/Thu, 01 Oct 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/secure-defaults/corb/Cross-Origin Read Blocking (CORB)は、攻撃者が特定のクロスオリジンのリソースを読み込むことを防ぐセキュリティ機構です1。 この保護機構は、攻撃者がクロスサイトのページ（attacker.com と sensitive.com など）が埋め込まれたプロセスのメモリを読み取れるようにするSpectreなどの投機的なサイドチャネル攻撃から保護するために作成されました。 CORBは、攻撃者が特定の機密性の高いクロスオリジンのリソースを攻撃者が制御するプロセスに読み込むのを防ぐことを目的としています。 たとえば、攻撃者がクロスオリジンのHTML、XML、JSONを imgタグに読み込もうとしようとすると、CORBはこれを阻止します。 CORBを使用すると、サーバがデータを返さなかったかのように処理されます。 リソースを分類するために、CORBは Content-Typeヘッダ、 nosniffヘッダ、およびその他のさまざまなヒューリスティックを使用します。 info Cross-Origin Resource Policy (CORP)は、CORB を適用・拡張するオプトインの保護です。 CORBを使用するときは、以下の点に注意してください。 現在はChromiumベースのブラウザのみがCORBをサポートしています。 CORBは、ナビゲーショナルリクエストに対して保護しません。つまり、プロセス外のiframeをサポートしないブラウザでは、framing protectionsが使用されていない場合、CORBで保護されたリソースは別のオリジンのプロセスで終了する可能性があります。 CORBは、攻撃者がCORBの結果を観察できる可能性があるため、new XS-Leak 手法を引き入れており、これによってさまざまな情報のリークが発生する可能性があります。 ただし、ほとんどの場合、これらのリークは投機的実行攻撃によってリークされる可能性のあるデータよりも影響は小さいものでしょう。 参考文献 # Cross-Origin Read Blocking for Web Developers, link ↩︎https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/opt-in/coop/Thu, 01 Oct 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/opt-in/coop/ウェブサイトの window オブジェクトにアクセスすることは、さまざまな XS-Leak 手法にとって共通の前提条件です。 Framing Protections は、攻撃者が window オブジェクトにアクセスするために iframe を使用できないようにすることができますが、 window.open(url) や window.opener の参照を通して開かれたウィンドウから、 window オブジェクトにアクセスすることを止めることはできません。 XS-Leaks を window.open で悪用することは、一般的に攻撃者にとって最も魅力のない方法と考えられています。なぜなら、ユーザーは開いているブラウザウィンドウでそれが起こるのを見ることができるからです。しかし、次のような場合には、正しい方法です。 Framing Protectionsがセットされている Same-Site Cookies with Lax Mode がセットされている(Strict モードとは対照的に，Lax モードではトップレベルのウィンドウを移動することができます) 他のウェブサイトがページへの任意のウィンドウ参照を得ることを防ぐために、アプリケーションは Cross-Origin-Opener-Policy (COOP) 1 2 を展開することができます。 COOPヘッダーには3つの値があります。 unsafe-none - これはデフォルトの値で、値が設定されていない場合にウェブサイトがどのように振る舞うかを示しています。 same-origin - これは最も厳しい値です。same-origin を設定すると、クロスオリジンのウェブサイトは新しいウィンドウを開いて window オブジェクトにアクセスすることができなくなります。もし、アプリケーションが window.open を使って別のウェブサイトを開いて通信することに依存している場合、same-origin によってブロックされます。これが問題になる場合は、代わりに same-origin-allow-popups を設定してください。 same-origin-allow-popups - この値はあなたのウェブサイトが window.open を使用することを許可しますが、他のウェブサイトがあなたのアプリケーションに対して window.open を使用することは許可されません。 可能であれば、same-originを設定することをお勧めします。same-origin-allow-popups を設定した場合は、 window.open で開くウェブサイトを確認し、そのウェブサイトが信頼できるものであることを確認するようにしてください。 考慮事項 # COOP はオプトインのメカニズムであり、非常に新しいものなので、開発者やセキュリティエンジニアは簡単に見落としてしまいます。 それでもこの防御メカニズムは重要です。 なぜなら、攻撃者が window.https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/opt-in/corp/Thu, 01 Oct 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/opt-in/corp/Cross-Origin Resource Policy（CORP）は、Webプラットフォームのセキュリティ機能であり、Webサイトが特定のリソースを他のオリジンによってロードされるのを防ぐことができます。 この保護はオプトイン防御であるためCORBを補完しますが、CORBはデフォルトで一部のクロスオリジン読み取りをブロックします。 CORPは、開発者が攻撃者によって制御されるプロセスに機密リソースが到達しないようにすることで、投機的実行攻撃とXSリークの両方から保護するように設計されています。 CORBとは異なり、この保護は、アプリケーションが保護をオプトインした場合にのみブラウザーに適用されます。 アプリケーションは、どのオリジンのグループ(‘same-site’,‘same-origin’, ‘cross-site’)がリソースの読み取りを許可されるかを定義できます。 アプリケーションが特定のリソースCORPヘッダーを「same-site」または「same-origin」として設定した場合、攻撃者はそのリソースを読み取ることができません。これは非常に強力で、推奨される保護です。 CORPを使用するときは、次の点に注意してください。 CORPはナビゲーションリクエストに対して保護しません。 つまり、プロセス外のiframeをサポートしていないブラウザでは、CORPで保護されたリソースは、[Framing protections]（https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/opt-in/xfo/）は使用されていない場合、他のオリジンのプロセスで終了する可能性があります。 CORPを使用すると、[a new XS-Leak]（https://webapppentestguidelines.github.io/xs-leaks/docs/attacks/browser-features/corp/）も付随し、攻撃者はあるリクエストでCORPが実施されたかどうかを検出することができます。 参考文献 #https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/opt-in/xfo/Thu, 01 Oct 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/opt-in/xfo/相当数のXS-Leaksがiframeのいくつかの特性に依存しています。もし攻撃者がページのコンテンツを iframe、frame、embed または object として埋め込むことができなければ、もはや攻撃は不可能になるかもしれません。これらのコンテンツに依存するXS-Leaksを軽減するために、ページはどのオリジンがそれらを埋め込むことができるかを禁じたり、あるいは選択したりすることができます。これは、X-Frame-Options header や CSP frame-ancestors directive を使用することで可能になります。 Framing Protections を適用したウェブサイトは、攻撃者のオリジンから埋め込むことができないため、コンテンツはレンダリングされず、JavaScript は実行されません。したがって、そのサブリソース（画像、JS、CSSなど）はいずれもブラウザによって取得できません。 tip CSP frame-ancestors directiveは、フレーミング保護を有効にする、より現代的な方法です。しかし、Internet Explorer ではサポートされていないので、多くの場合、X-Frame-Options Header と組み合わせて使うことが推奨されます。 Considerations # この保護機能は rely on framing のXS-Leaksに対して非常に有効であり、大多数のアプリケーションに対して容易に非破壊で実装することができます。この仕組みは、一部のXS-Leakを防ぐだけでなく、clickjackingのような攻撃も防ぐことができます。 Deployment # 通常、多くのアプリケーションは iframe 内にクロスオリジンで埋め込まれることを意図していないので、フレーミング保護を導入することは簡単です。このヘッダの利点については、この web.dev の記事を参照してください。https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/secure-defaults/partitioned-cache/Thu, 01 Oct 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/secure-defaults/partitioned-cache/cache probing攻撃を対策するために、ブラウザ開発者は、各Webサイトが個別のキャッシュを持つようにするパーティション化されたHTTPキャッシュ機能の実装に積極的に取り組んでいます。 cache probingは、ブラウザのHTTPキャッシュがすべてのWebサイトで共有されるという事実に依存しているため、パーティション化されたHTTPキャッシュは、多くのcache probingの手法を対策できます。 これは、キャッシュが要求元のサイトによってパーティショニングされていることを確認するためのキャッシュキーとして、firefox 1のようなタプル（(top-frame-site, resource-url) または chromium/chrome 2 のような (top-frame-site, framing-site, resource-url) ）を使って行われます。 これにより、攻撃者が異なるサイトのキャッシュされたコンテンツを操作することがより困難になります 3 4 5。 Safariは現在、パーティション化されたキャッシュを搭載しています6。 tip パーティション化されたキャッシュを使用しないブラウザの場合、アプリケーションがcache probing技術を対策するために展開できるother defensesがあります。 また、cache probing攻撃を対策するために、あるレベルのユーザインタラクションを必要とするように designed することも可能です。 その他の関連プロジェクト # WebKitのトラッキング防止技術 # Safari は (top-frame-site, resource URL) をキャッシュキーとして使用するパーティション化された HTTP キャッシュを実装しています。 これは、WebKit のより大きな Tracking Prevention プロジェクトの一部です。 FirefoxのFirst Party Isolation # First Party Isolationは、Firefoxの browser extension で、ドメインごとにクッキーや永続的なデータ（キャッシュなど）へのアクセスを制限するものです。 これには、ユーザ側でのオプトインが必要です。 考察 # パーティション化されたHTTPキャッシュは、いずれすべてのブラウザに搭載されるであろう有望なセキュリティ機能です。 これらのパーティショニング戦略は、ブラウザのキャッシュを活用するXS-Leakの手法のほとんどを軽減します。 将来的には、パーティション化されたキャッシュは他のブラウザリソースに拡張され、Socket Exhaustion XS-Leak などの他のXS-Leak手法の対策にも役立つかもしれません。 参考文献 # Top-level site partitioning (Gecko), link ↩︎https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/opt-in/same-site-cookies/Thu, 01 Oct 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/opt-in/same-site-cookies/SameSite Cookieは、クロスサイトリクエストを含むセキュリティ問題を修正するための、最もインパクトのある最新のセキュリティ機構の一つです。この機構によって、アプリケーションはブラウザに、同じサイト 1で発行されたリクエストにのみCookieを含めるように強制することができます。 SameSite Cookieには、None、Lax、Strict の 3 つのモードがあります。 SameSite Cookieのモード # SameSite Cookieのモードは以下の通りです。 None – SameSite Cookieによるすべての保護機能を無効化し、Cookieの旧来の動作に戻します。このモードは推奨されません。 important None 属性を設定するには、そのCookieに Secure 属性を付与しなければなりません。 [^1] Strict – ブラウザがクロスサイトリクエストにCookieを含めないようにします。これは、 <script src="example.com/resource">, <img src="example.com/resource">, fetch()、や XHR が元になるリクエストには Strict モードのCookieを付けずに送信します。 たとえユーザが example.com/resource のリンクをクリックしたとしてもそのリクエストにCookieは含まれません。 Lax – LaxとStrictの唯一の違いは、Laxモードではトップレベルの遷移によって発生するクロスサイトリクエストにはCookieを付けることができるということです。Lax モードはアプリケーションへの導線リンクを破壊しないため、設定がより簡単になります。残念ながら、攻撃者はwindow.open を通じてトップレベルの遷移を引き起こすことができ、それによって攻撃者はwindowオブジェクトへの参照を維持することができます。 考察 # StrictモードのCookieは最強のセキュリティ保護を提供しますが、既存のアプリケーションにStrictモードのSameSite Cookieを設定することは難しいでしょう。 SameSite Cookieは防弾でもなければ 2、すべてを解決できる技術ではありません。XS-Leaksに対するこの防御戦略を完全なものにするために、アプリケーションは他の追加的な防御を実装することを検討するべきです。例えば、COOP は Lax モードの SameSite Cookieが使われたとしても、最初のナビゲーション以降、攻撃者が window 参照を使ってページをコントロールするのを防ぐことができます。 important ブラウザによっては、Cookieのデフォルト動作としてLaxモードを使用しない場合があるので、SameSite属性を明示的に設定し、確実に実行されるようにしてください。 Google Chromeのデフォルトでは、SameSite属性を持たないCookieはLaxモードがデフォルトの動作になります。しかし、POSTリクエストで送信される際、設定されてから2分未満のCookieについては例外的にクロスサイトであってもCookieが付与されます。1 Cookies default to SameSite=Lax, link ↩︎ 実装 # この機構をWebアプリケーションに導入することに興味がある場合は web.dev の記事を見てください。https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/design-protections/subresource-protections/Thu, 01 Oct 2020 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/design-protections/subresource-protections/サブリソースを保護する設計の基本的な考え方は、攻撃者がサブリソースにユーザデータを返させることができなければ、サブリソースはXS-Leakの対象とはならないということです。 正しく実装されている場合、このアプローチは非常に強力な対策となりますが、実装が難しく、ユーザ体験に悪影響を与える可能性があります。 tip XS-Leakに特に注意すべきと認識している特定のリソースに、このアプローチを展開することは非常に効果的です。 ただし、この保護を一般的に展開するのは難しいため、アプリケーションはデフォルトのアプローチとして opt-in web platform security featuresを展開することを推奨します。 トークンベースの保護 # サブリソースの強力な保護は、すべてのリクエストにユーザ固有のトークンを含めることで実現できます。 これは、正しく実装されていれば、ほとんどのXS-Leakの手法から保護されます。 リソースのリクエストが正当であると検証するために、トークンを含めなければならないという考え方です。 なお、このトークンは攻撃者が自分のリクエストに含めることができないように、クライアントに提供しなければなりません。 example アプリケーションに検索バーがあるとします。 ユーザがメインページを読み込むと、サーバはページの本文のどこかに安全なトークンを含めます。 ユーザが何かを検索すると、/search?query=<QUERY>&token=<SECURE_TOKEN>にリクエストが送信されます。 バックエンドにて、受け取ったトークンが現在のユーザに対して有効であることを確認します。 有効でない場合には、リクエストが拒否されます。 このシナリオでは、攻撃者は、特定のユーザにおいて有効なトークンを取得できないため、エンドポイント対してリクエストを送信させる方法がありません。 これは、攻撃者が他のユーザのトークンを取得または偽造できないことに、依存することに注意してください。 もしそれが可能であれば、このアプローチは有効ではありません。 このスタイルの保護は、次の用途に適用できます。 APIエンドポイントや一般的な認証されたURLなどの認証済みのサブリソース。この場合、トークンも利用できますが、Same-Site Cookies などのセキュリティ緩和策の方が、大規模に展開しやすいかもしれません。 画像などの認証されていないサブリソースは、一部のタイプの Cache Probing Attacks を対策するためにこの保護を利用できます。これは有効ですが、cache probing攻撃を対策する他の戦略については Cache Protections を参照してください。 warning トークンベースの保護を実装すると、ユーザがリンク（ブックマークなど）を保存したり共有する機能が損なわれる可能性があります。 ユーザの同意 # もう1つの強力な対策は、機密データを返す前にユーザの操作を要求することです。 これにより、機密性の高いエンドポイントは、scriptまたはimgタグを介して含めることができなくなります。 たとえば、Facebookでは、検索結果やプライベートメッセージを表示する前にユーザの確認が必要です。 攻撃者はこのユーザとの対話を再現できないため、検索結果の内容をリークさせることはできません。 これは、特に機密性の高いエンドポイントを保護するために非常に有効な方法ですが、実装に時間がかかる可能性があることに注意してください。https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/opt-in/document-policies/Mon, 01 Jan 0001 00:00:00 +0000https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/opt-in/document-policies/Document-Policyは、別の実験的な機能ポリシー1と同様の実験的なメカニズムであり、ドキュメントの構成やドキュメント、フレームからの機能の削除（サンドボックス化）に関する機能をカバーするために使用されます。2 たとえば、次の例に示すように、レスポンスヘッダーに設定できます。 example Document-Policy: unsized-media=?0, document-write=?0, max-image-bpp=2.0, frame-loading=lazy ForceLoadAtTop # ForceLoadAtTop機能は、プライバシーに配慮したサイトに対して、Scroll To Text (と他のload-on-scroll動作) のオプトアウト機能を提供します。 この機能により、サイトは常にページの一番上に読み込まれ、テキストフラグメントやエレメントフラグメントを含むあらゆるscroll-on-loadの動作をブロックすることを示すことができます。 この機能は Document-Policy: force-load-at-top レスポンスヘッダーで設定することができます。 この機能は ID Attribute や Scroll to Text Fragment などの攻撃を防止するために有用です。 References # Document-Policy proposal, link ↩︎ Feature Policy, link ↩︎