https://webapppentestguidelines.github.io/xs-leaks/docs/defenses/opt-in/Recent content in Opt-In Mechanisms on XS-Leaks WikiHugo -- gohugo.ioja-jphttps://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/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/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/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 ↩︎