同一オリジンに境界を設ける Suborigins とは

Webセキュリティを考える上で大事な仕組みの一つに、Same-Origin Policyという仕組みがあります。
Originは「スキーム・ホスト・ポート」の組み合わせです。これらが一緒であれば、同一Originでありリソースへアクセスすることができます。


歴史的経緯や様々な理由により複数のアプリケーションが同一Originで提供されている場合があります。


たとえば、"チャット"や"ショッピング"の機能が以下の様なURLで提供されているような場合です。


実際、Googleの検索サービスと地図サービスは同一Originで提供されています。昔からあるリンクや、パフォーマンス、ブランディングのためのようです。


このように同じOriginで動作するアプリケーションでは、Same-Origin Policyによる保護はできず、片方に脆弱性があるともう片方も影響を受けてしまいます。


そこで、ページごとに セキュリティ境界を設けるために、「Suborigins」という仕様が提案されています。ChromeでもPer-page Suboriginsとして機能が実装されそうです。

W3C : https://w3c.github.io/webappsec-suborigins
Chromium : https://www.chromium.org/developers/design-documents/per-page-suborigins


今回は、簡単にざっと斜めよみしてみました。(理解が足りず間違い等あるかもしれません)

Suborigins

Suborigins は「スキーム・ホスト・ポート」が同じであっても、プログラム的に分離する仕組みを提供します。Suboriginsでは新たにsuborigin名前空間を提供し、「スキーム・ホスト・ポート・suborigin名前空間」が同一であれば同一ドメインとして扱われます。


Suborigins は新しい権限を追加するわけではなく、単純に別のOriginとして扱えるようにするだけです。RFC6454「The Web Origin Concept」で説明されるような"異なる2つのOrigin"と同様に扱われる必要があります。

The suborigin Directive

SuboriginsはContent Security Policyの新しいディレクティブとして定義されます。

  suborigin: testing
CORS

suborigin名前空間の定義されたページでは、どのようなURLへのXMLHttpRequests でもクロスドメインのものとして扱います。そして、特別にFiner-OriginヘッダとSuboriginヘッダが追加されたCORS手順が実行されます。通常付加されるOriginヘッダは追加されるべきではありません。レガシーなサーバが誤って受け入れないようにこの様な変更が必要です。


Finer-Originヘッダは、RFC6454で定義されているOriginヘッダと同じ値です。
Suboriginヘッダは、suborigin名前空間の文字列です。


同様の変更がレスポンスにも必要で、Access-Control-Allow-Finer-Originandヘッダ とAccess-Control-Allow-Suboriginヘッダが追加されます。

postMessage

postMessageを用いたクロスドメインのメッセージングは、CORSと同様の問題を引き起こします。
suborigin名前空間の定義されたページでは、event.originはnullとして受信者に読み込まれます。その代わりにevent.fineroriginに「スキーム・ホスト・ポート」、event.suboriginにsuborigin名前空間が設定されるべきです。

Workers

Workerの扱いは、Issueとして上げられていますがまだ仕様としては定義されていないようです。