サブドメインを持つSameSite Cookieについて、同じサイトと見なされるものは何ですか？
Samesite Cookie属性について、sub.example.comからのドメイン.example.comで同じサイト属性を持つCookieを設定した場合、それがother.example.comと同じサイトと見なされる場合、明確になりません。
Cookieの動作はCORSとは異なり、これを明確に明らかにするリソースを見つけるのに苦労しています。
SameSiteの「サイト」は、第2レベルのドメインmysite.comおよびトップレベルドメインmysite。com。
つまり、
login.mysite.comからcdn.mysite.comへのリクエストは、同じサイトのリクエストと見なされます。
[〜＃〜] but [〜＃〜]...ご想像のとおり、これで終わりではありません。この検証動作をわずかに変更する 公開サフィックスリスト があります。
どうして？ええと、レジストラやドメインの所有者ではなく、エンドユーザーがドメインの一部（サブドメイン）を制御するサイトが多数あるためです。例えば。 my-site.azurewebsites.net。
プライバシーとセキュリティの観点から、my-site.azurewebsites.netをスコープとするCookieをyour-site.azurewebsites.netに送信しないでください。また、特定のURLがこのタイプであるかどうかをブラウザが判断するアルゴリズム的な方法がないため、ブラウザが同じサイトの検証動作を変更するためのパブリックサフィックスリストが作成されました。したがって、azurewebsites.netは パブリックサフィックスリスト にリストされます。
したがって、パブリックサフィックスリストのサイトの場合、
my-site.azurewebsites.netからyour-site.azurewebsites.netへのリクエストはクロスサイトと見なされます。
仕様 について説明します。
"same-site" の定義は次のとおりです。
ターゲットのURIのオリジンの登録済みドメインがリクエストのクライアントの"site for cookies"と完全に一致する場合、またはリクエストにクライアントがない場合、リクエストは「同じサイト」です。それ以外の場合、リクエストは「クロスサイト」です。
特定のリクエスト（「リクエスト」）に対して、次のアルゴリズムは「同じサイト」または「クロスサイト」を返します。
「リクエスト」のクライアントが「null」の場合、「同じサイト」を返します。
"site"を "request"のクライアントの"site for cookies"とします（次のセクションで定義）。
「ターゲット」を「リクエスト」の現在のURLの登録済みドメインとします。
「site」が「target」と完全に一致する場合は、「same-site」を返します。
- 「クロスサイト」を返します。
ご覧のとおり、コアはsite for cookiesとregistered domainを比較することです。
registered domain から始めましょう。
オリジンの"登録済みドメイン"は、オリジンのホストのパブリックサフィックスとその左側のラベルです。つまり、「 https://www.example.com "の場合、パブリックサフィックスは「com」であり、登録済みドメインは「example.com」です。この概念は [〜＃〜] psl [〜＃〜] でより厳密に定義されており、「有効なトップレベルドメインプラス1」（eTLD + 1）とも呼ばれます。
[PSL]「パブリックサフィックスリスト」、n.d。、 https://publicsuffix.org/list/ 。
ただし、 https://publicsuffix.org/list/ で確認できるように、github.ioもリストに含まれているため、パブリックサフィックスです。したがって、registered domainsおよびhttps://me.github.ioのhttps://you.github.ioはme.github.ioおよびyou.github.ioであり、registered domainsのhttps://me.example.comおよび_ [SOMECODE]はhttps://you.example.comです。 _は両方ともexample.comです。
理由は、github.ioが https://publicsuffix.org/list/ にあるのに対し、example.comは https://publicsuffix.orgにないためです。/list / 。
動き続けましょう。では、"site for cookies"とは何ですか？
ここでの定義 であることがわかります
ユーザーエージェントのアドレスバーに表示されるURIは、ユーザーに直接公開される唯一のセキュリティコンテキストであるため、ユーザーが特定のWebサイトを信頼しているかどうかを判断するためにユーザーが合理的に信頼できる唯一の信号です。 そのURIのオリジンの登録済みドメインは、ユーザーが自分自身が相互作用していると信じる可能性が最も高いコンテキストを表します。このドメインに"top-level site"というラベルを付けます。
トップレベルのブラウジングコンテキストで表示されるドキュメントの場合、ここで停止できます。ドキュメントの「Cookieのサイト」はトップレベルのサイトです。
ネストされたブラウジングコンテキストで表示されるドキュメントの場合、[RFC7034]のセクション4で説明されている「複数のネストされたシナリオ」を説明するために、ドキュメントの祖先ブラウジングコンテキストのアクティブドキュメントのそれぞれの起源を監査する必要があります。ドキュメントの「Cookieのサイト」は、ドキュメントとその各祖先ドキュメントの発行元がトップレベルサイトと同じ登録済みドメインを持っている場合にのみ、トップレベルサイトです。それ以外の場合、「Cookieのサイト」は空の文字列です。
ドキュメント（「ドキュメント」）を指定すると、次のアルゴリズムは「Cookieのサイト」（登録済みドメインまたは空の文字列）を返します。
「トップドキュメント」を「ドキュメント」のブラウジングコンテキストのトップレベルのブラウジングコンテキストでアクティブなドキュメントとします。
「トップドキュメント」のサンドボックス化されたオリジンブラウジングコンテキストフラグが設定されている場合は、「トップオリジン」を「トップドキュメント」のURIのオリジンとし、それ以外の場合は「トップドキュメント」のオリジンとします。
「ドキュメント」を「ドキュメント」と「ドキュメント」の祖先ブラウジングコンテキストのアクティブドキュメントのそれぞれを含むリストとする。
「ドキュメント」の「アイテム」ごとに：
「アイテム」のサンドボックス化されたオリジンブラウジングコンテキストフラグが設定されている場合は「オリジン」を「アイテム」のURIのオリジンとし、それ以外の場合は「アイテム」のオリジンとします。
「Origin」のホストの登録済みドメインが「top-Origin」のホストの登録済みドメインと完全に一致しない場合は、空の文字列を返します。
「top-Origin」のホストの登録済みドメインを返します。
関連する定義は上記のとおりです。
例で終わります。
たとえば、ユーザーエージェントのアドレスバーに表示されるURIがhttps://me.github.ioの場合、https://you.github.ioからcross siteへのリクエストはhttps://me.github.ioになります。
ただし、ユーザーエージェントのアドレスバーに表示されるURIがhttps://me.example.comの場合、https://you.example.comからsame siteへのリクエストはhttps://me.example.comになります。
違いは、registered domainsのhttps://me.github.ioとhttps://you.github.ioがme.github.ioとyou.github.ioであるのに対し、registered domainsのhttps://me.example.comとhttps://you.example.comは両方ともexample.comです。
ターゲットURIの「登録済みドメイン」は、リクエストの「Cookieのサイト」の「完全一致」である必要があります。
「登録済みドメイン」とは次のとおりです。購入またはレンタルできるドメイン名、つまり パブリックサフィックス の1レベル下。
「Cookieのサイト」は通常、リクエストの「登録済みドメイン」でもあります。これは、ドキュメントが「トップレベルのブラウジングコンテキスト」にある場合、つまりほとんどのサイトに当てはまります。 「ネストされたブラウジングコンテキスト内の」ドキュメントの場合のみ、追加の要件は「ドキュメントとその各祖先ドキュメントの生成元がトップレベルサイトと同じ登録済みドメインを持っている」ことです。
要するに：サブドメインはカウントされません。登録可能なドメインを比較する必要があります。