スキームフル Same-Site

「Same-Site」の定義は、URL スキームを含めるように進化しているため、サイトの HTTP バージョンと HTTPS バージョン間のリンクはクロスサイトリクエストとして考慮されるようになっています。できる限り問題を回避できるようにデフォルトで HTTPS にアップグレードするか、どのような SameSite 属性が必要であるかに関する詳細をお読みください。

Nov 20, 2020

Available in: English, Русский, and 한국어

Appears in: 安全とセキュリティ

Steven Bingler

GitHub

Rowan Merewood

TwitterGitHubGlitch

スキームフル Same-Site は、単なる登録可能なドメインからスキームと登録可能なドメインへと（Web）サイトの定義を変更しています。詳細と例については、「「same-site」と「same-origin」を理解する」をご覧ください。

嬉しいのは、Web サイトがすでに完全に HTTPS にアップグレードされているのであれば、何も心配する必要はないということです。そのままで構いません。

Web サイトをまだ完全にアップグレードしていない場合は、これを優先事項する必要があります。ただし、サイト訪問者が HTTP と HTTPS の間を行き来する場合がある場合は、それらの一般的なシナリオと、関連する SameSite Cookie の動作の概要を以下に示しています。

これらの変更を有効にして、Chrome と Firefox の両方でテストできます。

• Chrome 86 で about://flags/#schemeful-same-site を有効にします。進捗状況は Chrome ステータスページで追跡してください。
• Firefox 79 の about:config で network.cookie.sameSite.schemeful を true に設定します。進捗状況は Bugzilla の問題で追跡してください。

Cookie のデフォルトを SameSite=Lax に変更した主な理由の 1 つは、クロスサイトリクエストフォージェリ（CSRF）から保護することでした。ただし、セキュリティで保護されていない HTTP トラフィックは、ネットワーク攻撃者が 同じサイトのセキュリティで保護された HTTPS バージョンで Cookie を使用できるように、その Cookie を改ざんする機会を与えています。スキーム間にクロスサイトの境界をさらに作成することで、これらの攻撃に対する防御をさらに高めることができます。

一般的なクロススキームのシナリオ #

ナビゲーション #

クロススキームバージョンの Web サイト間を移動する際（たとえば、http://site.example から https://site.example にリンクしている場合）、以前は SameSite=Strict Cookie を送信することができました。現在では、これはクロスサイトナビゲーションとして扱われるようになっており、つまり SameSite=Strict Cookie はブロックされるようになっています。

サブリソースの読み込み #

ここで行った変更は、完全な HTTPS へのアップグレード作業中の一時的な修正と見なす必要があります。

サブリソースの例には、XHR または Fetch で作成された画像、iframe、ネットワークリクエストが含まれます。

クロススキームサブリソースをページに読み込むすると、以前は SameSite=Strict またはSameSite=Lax Cookie を送信するか否かを設定できました。現在、これは他のサードパーティまたはクロスサイトのサブリソースと同じように処理されるようになっているため、SameSite=Strict または SameSite=Lax Cookie はブロックされます。

さらに、ブラウザがセキュリティで保護されていないスキームからのリソースをセキュリティで保護されたページに読み込むことを許可している場合でも、サードパーティまたはクロスサイトの Cookie には Secure が必要なため、これらのリクエストではすべての Cookie がブロックされます。

フォームの POST 送信 #

クロススキームバージョンの Web サイト間で POST 送信を行うと、以前は SameSite=Lax または SameSite=Strict に設定された Cookie を送信できました。現在では、これはクロスサイト POST 送信として扱われており、SameSite=None の Cookie のみを送信できるようになっています。このシナリオは、デフォルトでセキュリティで保護されていないバージョンを提供しているサイトで発生する可能性がありますが、サインインまたはチェックアウトフォームの送信時にユーザーをセキュリティで保護されたバージョンにアップグレードするサイトで使用されている可能性があります。

サブリソースと同様に、リクエストがセキュリティで保護された HTTPS から セキュリティで保護されていない HTTP に移行する場合、サードパーティまたはクロスサイトの Cookie には Secure が必要であるため、これらのリクエストではすべての Cookie がブロックされます。

自分のサイトをテストするには？ #

Chrome と Firefox で開発者向けツールとメッセージングを使用できます。

Chrome 86 では、スキームフル Same-Site 問題は、DevTools の［Issue］タブに含まれます。サイトでは以下の問題がハイライトされる場合があります。

ナビゲーションの問題:

• 「Migrate entirely to HTTPS to continue having cookies sent on same-site requests」- Chrome の将来のバージョンで Cookie がブロックされるという警告です。
• 「Migrate entirely to HTTPS to have cookies sent on same-site requests」- Cookie がブロックされているという警告です。

サブリソースの読み込みの問題:

• 「Migrate entirely to HTTPS to continue having cookies sent to same-site subresources」または「Migrate entirely to HTTPS to continue allowing cookies to be set by same-site subresources」- Chrome の将来のバージョンで Cookie がブロックされるという警告です。
• 「Migrate entirely to HTTPS to have cookies sent to same-site subresources」または「Migrate entirely to HTTPS to allow cookies to be set by same-site subresources」- Cookie がブロックされているという警告です。後者の警告は、フォームを POST 送信するときにも表示される可能性があります。

詳細については、「スキームフル Same-Site のテストとデバッグのヒント」をご覧ください。

Firefox 79 の about:config で、network.cookie.sameSite.schemeful を true に設定すると、コンソールにスキームフル Same-Site の問題に関するメッセージが表示されます。サイトで以下のようなメッセージが表示される場合があります。

• 「 Cookie cookie_name will be soon treated as cross-site cookie against http://site.example/ because the scheme does not match.」
• 「Cookie cookie_name has been treated as cross-site against http://site.example/ because the scheme does not match.」

よくある質問 #

私のサイトはすでに完全に HTTPSで提供されていますが、ブラウザの DevTools で問題が表示されているのはなぜですか？ #

一部のリンクとサブリソースが依然としてセキュリティで保護されていない URL を指している可能性があります。

この問題を修正する 1 つの方法は、HTTP Strict-Transport-Security（HSTS）と includeSubDomain ディレクティブを使用することです。HSTS + includeSubDomain を使用すると、ページの 1 つに誤ってセキュリティで保護されていないリンクが含まれている場合でも、ブラウザは代わりにセキュリティで保護されたバージョンを自動的に使用します。

HTTPS にアップグレードできない場合は？ #

ユーザーを保護するためにサイトを完全に HTTPS にアップグレードすることを強くお勧めしますが、自分でアップグレードできない場合は、ホスティングプロバイダーに相談して、そのオプションを提供できるかどうかを確認することをお勧めします。セルフホストの場合は、Let's Encrypt に証明書をインストールして構成するためのツールが多数用意されています。また、HTTPS 接続を提供できる CDN またはその他のプロキシの背後にサイトを移動することを調べることもできます。

それでも不可能な場合は、影響を受ける Cookie の SameSite 保護を緩和させてみてください。

• SameSite=Strict Cookie のみがブロックされている場合は、保護を Lax に下げることができます。
• Strict と Lax の両方がブロックされており、Cookie が安全な URL に送信されている（またはそこから設定されている）場合は、保護を None に下げることができます。
  • Cookie を送信する（または Cookie を設定する）URL が安全でない場合、この回避策は失敗します。これは、SameSite=None に Secure 属性が必要であるためです。つまり、これらの Cookie は、安全でない接続を介して送信または設定されない可能性があります。この場合、サイトが HTTPS にアップグレードされるまで、その Cookie にアクセスすることはできません。
  • 最終的にサードパーティの Cookie は徐々に完全に廃止されるため、これは一時的な措置であることを忘れないでください。

SameSite 属性を指定していない場合、Cookie にどのように影響しますか？ #

SameSite 属性のない Cookie は、 SameSite=Lax を指定しているかのように扱われ、同じクロススキームの動作がこれらの Cookie にも適用されます。安全でないメソッドに対する一時的な例外が引き続き適用されることに注意してください。詳細については、Cromium SameSite FAQ の「Lax + POST の緩和」をご覧ください。

WebSocket はどのような影響を受けますか？ #

WebSocket 接続は、ページと同じセキュリティ設定である場合に、Same-Site と見なされます。

Same-Site（同一サイト）:

• https:// からの wss:// 接続
• http:// からの ws:// 接続

クロスサイト:

• http:// からの wss:// 接続
• https:// からの ws:// 接続

写真提供: Julissa Capdevilla（Unsplash）