October 1, 2020
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 ↩︎
...
October 1, 2020
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 の記事を見てください。
...
October 1, 2020
サブリソースを保護する設計の基本的な考え方は、攻撃者がサブリソースにユーザデータを返させることができなければ、サブリソースは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では、検索結果やプライベートメッセージを表示する前にユーザの確認が必要です。 攻撃者はこのユーザとの対話を再現できないため、検索結果の内容をリークさせることはできません。
これは、特に機密性の高いエンドポイントを保護するために非常に有効な方法ですが、実装に時間がかかる可能性があることに注意してください。
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 ↩︎