Subresource Protections

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では、検索結果やプライベートメッセージを表示する前にユーザの確認が必要です。攻撃者はこのユーザとの対話を再現できないため、検索結果の内容をリークさせることはできません。

これは、特に機密性の高いエンドポイントを保護するために非常に有効な方法ですが、実装に時間がかかる可能性があることに注意してください。