November 30, 2020
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を参照してください。
...
November 30, 2020
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.
...
November 30, 2020
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 ↩︎
November 30, 2020
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 important
...
November 30, 2020
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.
...
October 16, 2020
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と省略して記載しています。
...
October 1, 2020
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 ↩︎
October 1, 2020
ウェブサイトの 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.
...
October 1, 2020
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が実施されたかどうかを検出することができます。 参考文献 #
October 1, 2020
相当数の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 の記事を参照してください。