|
|
ウェブページ上のリソースがアクセスする Cookie が、ユーザーの訪問先サイトと一致する場合、同一サイトすなわち「ファースト パーティ」コンテキストとなる
|
Cookie のセキュリティと透過性を実現するための新しいモデル
現在のところ、Cookie がファースト パーティ コンテキストからのみアクセスできるようにする場合、デベロッパーは 2 つの設定（
SameSite=Lax または
SameSite=Strict）のいずれかを選んで外部アクセスを防ぐことができます。しかし、この推奨手法に従っているデベロッパーはほとんどおらず、大多数の同一サイト Cookie は
クロスサイト リクエスト フォージェリ攻撃などの脅威に不要にさらされています。
そこで、ウェブサイトとユーザーを保護するため、デフォルトで安全な状態にする新しいモデルでは、明示的な指定がない限り、すべての Cookie を外部アクセスからの保護対象と見なします。デベロッパーは新しい Cookie 設定
SameSite=None を使い、Cookie をクロスサイト アクセスの対象として指定する必要があります。
SameSite=None 属性が存在する場合は、クロスサイト Cookie に HTTPS 接続のみでアクセスできるように、
Secure 属性も追加する必要があります。これでクロスサイト アクセスに関連するすべてのリスクが緩和されるわけではありませんが、ネットワーク攻撃に対する保護は実現できます。
このようにクロスサイト Cookie を明示的に宣言すると、すぐにセキュリティを向上できるだけでなく、透過性が高まり、ユーザーの選択肢も増えます。たとえば、1 つのサイトからアクセスされる Cookie と複数のサイトからアクセスされる Cookie を分けて管理するなど、ブラウザで Cookie の細やかな制御を行えるようになります。
Chrome は 2020 年 2 月より新しいモデルを適用
2 月の Chrome 80 以降、SameSite 値が宣言されていない Cookie は
SameSite=Lax として扱われます。外部アクセスは、
SameSite=None; Secure 設定のある Cookie のみ可能になります。ただし、これらが安全な接続からアクセスされることが条件です。Chrome プラットフォームの
SameSite=None と
Secure の Status Tracker は、最新のリリース情報に基づいて今後もアップデートが継続されます。
Mozilla は、Firefox でクロスサイト Cookie の
SameSite=None; Secure 要件を
実装する予定で、新しい Cookie 分類モデルのサポートを確約しています。Microsoft は先日、Microsoft Edge 80 より試験運用版としてこのモデルの実装を開始する計画を
発表しました。
準備方法と既知の複雑なケース
クロスサイト Cookie を管理している方は、Cookie に SameSite=None; Secure 設定を適用する必要があります。ほとんどのデベロッパーは簡単な実装で済むはずです。しかし、以下のような複雑なケースや特殊なケースを判別するため、すぐにテストを開始することを強くお勧めします。
- 現時点で、すべての言語やライブラリが None 値をサポートしているわけではありません。サポートされていない場合は、デベロッパーは直接 Cookie ヘッダーを設定する必要があります。こちらの Github リポジトリには、さまざまな言語、ライブラリ、フレームワークで SameSite=None; Secure を実装する手順が示されています。
- 特定のバージョンの Chrome、Safari、UC Browser など、一部のブラウザは None 値を意図しない方法で処理する可能性があります。その場合、デベロッパーはそのようなクライアント向けに例外処理をコーディングする必要があります。これには、古いバージョンの Chrome が提供している Android の WebView も含まれます。既知の互換性のないクライアントの一覧はこちらです。
- アプリ デベロッパーは、None 値と互換性のある Chrome のバージョンに基づいて Android WebView 用に適切な SameSite Cookie 設定を宣言するようにします。これは、HTTP（S）ヘッダーを通してアクセスされる Cookie と、Android WebView の CookieManager API を通してアクセスされる Cookie の両方について行う必要があります。ただし、新しいモデルによって Android WebView が影響を受けるようになるのはまだ先のことです。
- シングル サインオンなどのサービスや社内アプリケーションが 2 月のリリースに対応できない場合、企業の IT 管理者が特別なポリシーを実装し、Chrome ブラウザを一時的に以前の動きに戻す必要があるかもしれません。
- ファースト パーティ コンテキストとサードパーティ コンテキストの両方でアクセスする Cookie がある場合、ファースト パーティ コンテキストで別の Cookie を使って SameSite=Lax によるセキュリティのメリットを得ることを検討してください。
SameSite Cookie の説明には、前述の状況についての具体的なガイダンスや、問題や質問を送信できるチャンネルが記載されています。
管理しているサイトや Cookie に対する Chrome の新しい動作の影響をテストしたい場合は、Chrome 76 以降で chrome://flags を開き、試験運用版機能である [SameSite by default cookies] と [Cookies without SameSite must be secure] を有効にします。また、一部の Chrome 79 ベータ版ユーザーは、これらの試験運用版機能が自動的に有効になります。試験運用版機能を有効にしたベータ版ユーザーによっては、新しいモデルをまだサポートしていないサービスによって互換性に関する問題が起きることがあります。ユーザーは、chrome://flags に移動してベータ版の試験運用を無効にすることで、対象の機能をオプトアウトできます。
同一サイト コンテキストのみでアクセスされる Cookie（同一サイト Cookie）を管理している場合、何もする必要はありません。SameSite 属性がない、または値が設定されていない場合でも、Chrome は外部エンティティからこれらの Cookie へのアクセスを自動的にブロックします。ただし、すべてのブラウザがデフォルトで同一サイト Cookie を保護するとは限らないため、適切な SameSite 値（
Lax または
Strict）を設定し、デフォルトのブラウザの動作に依存しないことを強くお勧めします。
最後に、皆さんのウェブサイトにサービスを提供しているベンダーなどの対応を懸念している方へお伝えします。必要な設定が行われていないクロスサイト Cookie がページに含まれる場合、Chrome 77 以降のデベロッパー ツールのコンソールに次の警告が表示されます。この警告を確認してください。
2 月の Chrome 80 のリリースまでの数か月間で必要な変更を実装するプロバイダ（一部の Google 製サービスを含む）もあります。対応状況を確認するために、パートナーに連絡してみるのもよいでしょう。
