对于相同站点的 cookie 属性,我不清楚是否设置了域 .example.com 的 cookie,来自 sub.example.com 的具有相同站点属性,如果它将被视为与 other.example.com 相同的站点。
Cookie 行为与 CORS 不同,我无法找到明确说明这一点的资源。
对于相同站点的 cookie 属性,我不清楚是否设置了域 .example.com 的 cookie,来自 sub.example.com 的具有相同站点属性,如果它将被视为与 other.example.com 相同的站点。
Cookie 行为与 CORS 不同,我无法找到明确说明这一点的资源。
SameSite 中的“站点”是指二级域mysite .com和顶级域mysite 的组合。com。
这意味着来自
login.mysite.com
to的请求cdn.mysite.com
将被视为同站点请求。
但是......正如你可能想象的那样,它并没有就此结束。有一个公共后缀列表稍微改变了这个验证行为。
为什么?好吧,因为有许多站点是最终用户而不是注册商或域所有者控制域的一部分(子域)。例如my-site.azurewebsites.net
。
从隐私和安全的角度来看,范围为的 cookiemy-site.azurewebsites.net
绝对不应发送到your-site.azurewebsites.net
. 而且,由于您的浏览器没有算法方法来确定特定 URL 是否属于这种类型,因此为浏览器创建了公共后缀列表以更改其同站点验证行为。因此,azurewebsites.net
被列在公共后缀列表中。
因此,对于公共后缀列表中的站点,来自
my-site.azurewebsites.net
to的请求your-site.azurewebsites.net
将被视为跨站点。
让我解释一下规范。
如果请求的目标 URI 的源注册域与请求的客户端的“cookie 站点”完全匹配,或者请求没有客户端,则请求是“相同站点”。否则,该请求是“跨站点”的。
对于给定的请求(“请求”),以下算法返回“相同站点”或“跨站点”:
- 如果“request”的客户端为“null”,则返回“same-site”。
- 让“站点”成为“请求”客户端的“cookie 站点”(如以下部分中所定义)。
- 设“target”为“request”当前url的注册域。
- 如果“site”与“target”完全匹配,则返回“same-site”。
- 返回“跨站点”。
如您所见,核心是与 进行site for cookies
比较registered domain
。
让我们从registered domain
.
源的“注册域”是源主机的公共后缀加上其左侧的标签。即对于“https://www.example.com”,公共后缀为“com”,注册域名为“example.com”。这个概念在PSL中定义更为严格,也被称为“有效顶级域加一”(eTLD+1)。
[PSL]“公共后缀列表”,nd,https://publicsuffix.org/list/。
但是,正如您在https://publicsuffix.org/list/中看到的那样,github.io
它也在列表中,这意味着它是一个公共后缀。因此, the registered domains
of https://me.github.io
and https://you.github.io
are me.github.io
andyou.github.io
而 the registered domains
of https://me.example.com
and https://you.example.com
are both example.com
。
原因是github.io
在https://publicsuffix.org/list/而不example.com
在https://publicsuffix.org/list/中。
让我们继续前进。那么,什么是"site for cookies"
?
我们可以在这里找到它的定义
显示在用户代理地址栏中的 URI 是唯一直接暴露给用户的安全上下文,因此是用户可以合理依赖的唯一信号来确定他们是否信任特定网站。该 URI 源的注册域 表示用户最有可能认为自己正在交互的上下文。我们将此域标记为“顶级站点”。
对于在顶级浏览上下文中显示的文档,我们可以到此为止:文档的“cookie 站点”是顶级站点。
对于在嵌套浏览上下文中显示的文档,我们需要审核每个文档的祖先浏览上下文的活动文档的来源,以便解释 [RFC7034] 第 4 节中描述的“多嵌套场景”。当且仅当文档及其每个祖先文档的来源与顶级站点具有相同的注册域时,文档的“cookie 站点”才是顶级站点。否则,它的“cookie 站点”是空字符串。
给定一个文档(“文档”),以下算法返回其“cookie 站点”(注册域或空字符串):
- 让“top-document”成为“document”浏览上下文的顶级浏览上下文中的活动文档。
- 如果设置了“top-document”的沙盒源浏览上下文标志,则让“top-origin”成为“top-document”的 URI 的来源,否则为“top-document”的来源。
- 让“文档”是一个包含“文档”和每个“文档”的祖先浏览上下文的活动文档的列表。
- 对于“文档”中的每个“项目”:
1. Let "origin" be the origin of "item"'s URI if "item"'s
sandboxed origin browsing context flag is set, and "item"'s
origin otherwise.
2. If "origin"'s host's registered domain is not an exact match
for "top-origin"'s host's registered domain, return the empty
string.
- 返回“top-origin”主机的注册域。
相关定义如上。
我们可以用一个例子来结束。
例如,如果用户代理的地址栏中显示的 URI是 ,则来自https://me.github.io
to的请求是.https://you.github.io
cross site
https://me.github.io
但是,如果用户代理的地址栏中显示的 URI是 ,则来自https://me.example.com
to的请求是.https://you.example.com
same site
https://me.example.com
不同之处在于registered domains
of https://me.github.io
and https://you.github.io
areme.github.io
和you.github.io
while the and are both 。registered domains
https://me.example.com
https://you.example.com
example.com
目标 URI 的“注册域”必须与请求的“cookie 站点”“完全匹配”。
您知道什么是“注册域名”:您可以购买或租用的域名,即比公共后缀低一级。
“cookie 站点”通常也是“注册域”——这里是请求的。当文档“处于顶级浏览上下文”时,即对于大多数站点,这是正确的。仅对于“嵌套浏览上下文”中的文档,附加要求是“文档及其每个祖先文档的来源与顶级站点具有相同的注册域”。
简而言之:子域不算数。您必须比较可注册的域。