最新のウェブ アプリケーションでユーザーデータを安全にホスト

David Dworken
David Dworken

多くのウェブ アプリケーションでは、ユーザーが制御するコンテンツを表示する必要があります。これは、ユーザーがアップロードした画像(プロフィール写真など)を提供するだけのシンプルなものから、ユーザー制御の HTML のレンダリング(ウェブ開発チュートリアルなど)のような複雑なものまで、さまざまです。セキュリティを確保することは常に困難でした。そこで Google では、ほとんどの種類のウェブ アプリケーションに適用できる、簡単で安全なソリューションを見つけることに取り組んできました。

信頼できないコンテンツを分離するための従来のソリューション

ユーザーが管理するコンテンツを安全に配信するための従来の解決策は、サンドボックス ドメインと呼ばれるものを使用することです。基本的な考え方は、アプリケーションのメインドメインが example.com であれば、信頼できないコンテンツをすべて exampleusercontent.com で提供できるということです。これら 2 つのドメインはクロスサイトであるため、exampleusercontent.com 上の悪意のあるコンテンツが example.com に影響を与えることはありません。
この方法を使用すると、画像、ダウンロード、HTML など、信頼できないあらゆる種類のコンテンツを安全に配信できます。画像やダウンロードにこれを使用する必要はないように思えるかもしれませんが、使用することで、特に従来のブラウザでは、コンテンツ スニッフィングのリスクを回避できます。
サンドボックス ドメインは業界で広く使用されており、長い間効果を発揮しています。ただし、この 2 つの大きなデメリットがあります。

  • アプリケーションは多くの場合、コンテンツへのアクセスを 1 人のユーザーに制限する必要があります。これには認証と認可の実装が必要です。サンドボックス ドメインは意図的に Cookie をメインのアプリケーション ドメインと共有しないため、安全に行うことは非常に困難です。認証をサポートするには、サイトで機能の URL を使用するか、サンドボックス ドメイン用の認証 Cookie を個別に設定する必要があります。2 番目の方法は、多くのブラウザがデフォルトでクロスサイト Cookie を制限している最新のウェブでは特に問題です。
  • ユーザー コンテンツはメインサイトから分離されていますが、他のユーザー コンテンツからは分離されていません。これにより、悪意のあるユーザー コンテンツがサンドボックス ドメイン内の他のデータを攻撃するリスクが生じます(同一オリジンのデータを読み取るなど)。

また、サンドボックス ドメインではリソースが分離されたドメインに明確にセグメント化されるため、フィッシングのリスクを軽減できます。

ユーザー コンテンツを提供するための最新のソリューション

ウェブは進化を遂げるにつれ、信頼できないコンテンツをより簡単かつ安全に提供する方法が増えてきました。さまざまなアプローチがあるので、Google で現在幅広く使用されている 2 つのソリューションの概要を説明します。

アプローチ 1: 非アクティブ ユーザー コンテンツを提供する

サイトで非アクティブなユーザー コンテンツ(HTML や JavaScript 以外のコンテンツ、画像、ダウンロードなど)のみを配信する場合は、隔離されたサンドボックス ドメインなしでも安全に処理できるようになりました。主なステップは次の 2 つです。

  • Content-Type ヘッダーには、すべてのブラウザでサポートされ、アクティブなコンテンツが含まれないことが保証された、よく知られた MIME タイプに必ず設定します(不明な場合は、application/octet-stream を使用するのが安全です)。
  • また、ブラウザがレスポンスを完全に分離できるように、常に以下のレスポンス ヘッダーを設定してください。
レスポンス ヘッダー 目的

X-Content-Type-Options: nosniff

コンテンツ スニッフィングを防ぎます

Content-Disposition: attachment; filename="download"

レンダリングではなくダウンロードをトリガーする

Content-Security-Policy: sandbox

コンテンツを別のドメインに配信されるかのようにサンドボックス化する

Content-Security-Policy: default-src ‘none'

JavaScript の実行(およびサブリソースを含める)を無効にします

Cross-Origin-Resource-Policy: same-site

クロスサイト ページにページが含まれないようにします

このヘッダーの組み合わせにより、ユーザーはレスポンスをアプリケーションでサブリソースとしてのみ読み込むことや、ファイルとしてダウンロードすることができます。さらに、このヘッダーは、CSP サンドボックス ヘッダーと default-src 制限により、ブラウザのバグに対する複数の保護レイヤを提供します。全体として、上記の設定により、この方法で提供されるレスポンスがインジェクションや分離の脆弱性につながることはないという高い信頼性が得られます。

多層防御

一般に、上記のソリューションは XSS に対して十分な防御を行いますが、セキュリティをさらに強化するために適用できる追加の強化策がいくつかあります。

  • IE11 との互換性を確保するために X-Content-Security-Policy: sandbox ヘッダーを設定します。
  • Content-Security-Policy: frame-ancestors 'none' ヘッダーを設定して、エンドポイントの埋め込みをブロックします。
  • 次の方法で、分離されたサブドメインでユーザー コンテンツをサンドボックス化します。
    • 分離されたサブドメインでユーザー コンテンツを提供する(たとえば、Google は product.usercontent.google.com などのドメインを使用します)。
    • Cross-Origin-Opener-Policy: same-originCross-Origin-Embedder-Policy: require-corp を設定して、クロスオリジン分離を有効にします。

アプローチ 2: アクティブ ユーザー コンテンツを提供する

アクティブ コンテンツ(HTML や SVG 画像など)を安全に配信することもできます。この場合、従来のサンドボックス ドメイン手法の弱点は生じません。
最も簡単な方法は、Content-Security-Policy: sandbox ヘッダーを利用してレスポンスを分離するようブラウザに伝えることです。現在、すべてのウェブブラウザがサンドボックス ドキュメントのプロセス分離を実装しているわけではありませんが、ブラウザのプロセス モデルの継続的な改良により、サンドボックス化されたコンテンツと埋め込みアプリケーションの分離が向上する可能性があります。SpectreJSレンダラの侵害攻撃が脅威モデルの範囲外である場合は、CSP サンドボックスで十分な解決策となる可能性があります。
Google では、サンドボックス ドメインの概念をモダナイズすることで、信頼できないアクティブなコンテンツを完全に分離できるソリューションを開発しました。基本的な考え方は次のとおりです。

  • 新しいサンドボックス ドメインを作成し、パブリック サフィックス リストに追加します。たとえば、PSL に exampleusercontent.com を追加すると、foo.exampleusercontent.combar.exampleusercontent.com をクロスサイト、つまり互いに完全に分離できます。
  • *.exampleusercontent.com/shim に一致する URL はすべて、静的 shim ファイルにルーティングされます。この shim ファイルには、message イベント ハンドラをリッスンし、受け取ったコンテンツをレンダリングする短い HTML と JavaScript スニペットが含まれています。
  • これを使用するために、プロダクトは $RANDOM_VALUE.exampleusercontent.com/shim に iframe またはポップアップを作成し、postMessage を使用して信頼できないコンテンツを shim に送信してレンダリングします。
  • レンダリングされたコンテンツは blob に変換され、サンドボックス化された iframe 内にレンダリングされます。

従来のサンドボックス ドメイン アプローチと比較すると、すべてのコンテンツが個別のサイトで完全に分離されます。また、レンダリングするデータの取得をメインアプリケーションに処理させることで、ケーパビリティ URL を使用する必要がなくなりました。

おわりに

これら 2 つのソリューションを組み合わせることで、googleusercontent.com などの従来のサンドボックス ドメインから、サードパーティ Cookie のブロックと互換性のある、より安全なソリューションに移行できるようになります。Google では、これらのソリューションを使用するためにすでに多くのプロダクトを移行しており、来年にはさらに多くの移行を計画しています。