浏览器cookie域是如何工作的?

由于奇怪的域/子域cookie问题，我得到了，我想知道浏览器如何处理cookie。如果他们用不同的方式做这件事，知道其中的区别也会很好。

换句话说，当浏览器接收到一个cookie时，该cookie可能有一个域和一个路径附加到它。或者不是，在这种情况下，浏览器可能会用一些默认值代替它们。问题1:它们是什么?

稍后，当浏览器准备发出请求时，它检查它的cookie并过滤掉它应该为该请求发送的cookie。它通过将它们与请求路径和域进行匹配来做到这一点。问题2:匹配规则是什么?
补充:< / >强

我问这个问题是因为我对一些边缘情况感兴趣。如:

  • .example.com的cookie对www.example.com可用吗?
  • .example.com的cookie对example.com可用吗?
  • example.com的cookie对www.example.com可用吗?
  • example.com的cookie对anotherexample.com可用吗?
  • www.example.com是否能够为example.com设置cookie ?
  • www.example.com是否能够为www2.example.com设置cookie ?
  • www.example.com是否能够为.com设置cookie ?
  • 等。

补充2:

还有，谁能建议一下我应该如何设置cookie，以便:

  • 它可以通过www.example.com或example.com来设置;
  • 它可以通过www.example.com和example.com访问。
283530 次浏览
小开

要获得更广泛的覆盖，请查看RFC2965的内容。当然，这并不意味着所有浏览器的行为都完全相同。

但是，通常情况下，如果cookie中没有指定默认路径，则默认路径是Set-Cookie报头到达的URL中的路径。类似地，Domain的默认值是来自Set-Cookie的URL中的完整主机名。

域的匹配规则要求cookie domain与发出请求的主机相匹配。cookie可以通过include *指定更宽的域匹配。在Set-Cookie的域属性中(这一区域浏览器可能不同)。匹配路径(假设域匹配)很简单，请求的路径必须在cookie上指定的路径内。通常会话cookie设置为path=/或path=/applicationName/，因此该cookie对进入应用程序的所有请求都可用。

__Response to Added:__
  • .example.com的cookie是否可用于www.example.com?是的
  • example.com的cookie是否可用于example.com?不知道
  • example.com的cookie是否可用于www.example.com?不但是… *
  • example.com的cookie是否可用于anotherexample.com?没有
  • www.example.com能够为example.com设置cookie吗?是的
  • www.example.com能够为www2.example.com设置cookie吗?没有 (除了通过。example.com)
  • www.example.com能够为。com设置cookie吗?没有 (不能在命名空间中设置这么高的cookie，也不能为。co.uk之类的东西设置cookie)。

*我现在无法测试这个，但我有一个暗示，至少IE7/6会把路径example.com当作.example.com。

小开
最佳答案

虽然现在有应该定义cookie的RFC 2965 (Set-Cookie2，已经过时的RFC 2109)，但大多数浏览器并不完全支持它，而只是遵循Netscape的原始规格。

域属性值和有效域之间有区别:前者来自Set-Cookie报头字段，后者是该属性值的解释。根据RFC 2965，以下应适用:

  • 如果set - cookie报头字段不具有域属性，则有效域是请求的域。
  • 如果存在域属性，它的值将被用作有效域(如果值不以.开头，它将由客户端添加)。

有了有效域，它还必须domain-match当前被请求设置的域;否则cookie将被修改。同样的规则也适用于选择在请求中发送的cookie。

将这些知识映射到你的问题上，下面的方法应该适用:

  • 带有Domain=.example.com 将的Cookie可用于www.example.com
  • 带有Domain=.example.com 将的Cookie可用于example.com
  • 带有Domain=example.com的Cookie将被转换为.example.com，因此将也可用于www.example.com
  • 带有Domain=example.com的Cookie将被不用于anotherexample.com
  • www.example.com 将可以为example.com设置cookie
  • www.example.com将能够为www2.example.com设置cookie
  • www.example.com将能够为com设置cookie

要为/by www.example.com和example.com设置和读取cookie，分别为.www.example.com和.example.com设置cookie。但是第一个(.www.example.com)只能被该域以下的其他域访问(例如foo.www.example.com或bar.www.example.com)，其中.example.com也可以被example.com以下的任何其他域访问(例如foo.example.com或.example.com0)。

小开

www.example.com是否能够为.com设置cookie ?

不能，但是example.com.fr可以为example2.com.fr设置一个cookie。Firefox通过维护一个tld列表:http://securitylabs.websense.com/content/Blogs/3108.aspx来防止这种情况

显然Internet Explorer不允许双字母域设置cookie，我想这解释了为什么o2.ie简单地重定向到o2online.ie。我常常这样想。

小开

众所周知，rfc并不能反映现实。

最好检查draft-ietf-httpstate-cookie，工作进行中。

小开

我很惊讶地读到3.3.2节关于拒绝cookie的内容:

https://www.rfc-editor.org/rfc/rfc2965

这意味着浏览器应该拒绝来自x.y.z.com的域名为。z.com的cookie，因为“x.y”包含一个点。所以，除非我误解了RFC和/或上面的问题，否则可能会添加一些问题:

.example.com的cookie是否可用于www.yyy.example.com?不。

一个由源服务器www.yyy.example.com设置的cookie，域名为。example.com，它的值会被用户代理发送到xxx.example.com吗?不。

小开

有一些规则决定浏览器是否接受set -header响应报头(服务器端cookie写入)，对于使用Javascript的cookie集有一个稍微不同的规则/解释(我还没有测试VBScript)。

然后，有一些规则确定浏览器是否会随页面请求一起发送cookie。

主要的浏览器引擎在处理域匹配和解释路径值中的参数方面存在差异。你可以在文章不同的浏览器处理cookie有何不同中找到一些经验证据

小开

这个问题的最后一个(确切地说是第三个)RFC是RFC-6265(废弃RFC-2965，反过来又废弃RFC-2109)。

根据它如果服务器忽略了Domain属性，用户代理将只将cookie返回给源服务器(给定资源所在的服务器)。但是也是警告，一些现有的用户代理处理一个缺失的Domain属性，就像Domain属性存在并且包含当前主机名一样(例如，如果example.com返回一个没有Domain属性的Set-Cookie报头，这些用户代理也会错误地将cookie发送到www.example.com)。

当Domain属性被指定时，它将被视为完整的域名(如果属性中有前导点，它将被忽略)。服务器必须匹配属性中指定的域(具有完全相同的域名或它的子域名)才能获得此cookie。更准确地说，它这里指定的。

举个例子:

  • cookie属性Domain=.example.com等价于Domain=example.com
  • 具有这样Domain属性的cookie将为example.com和www.example.com的可用
  • 具有这样Domain属性的cookie将为another-example.com的不可用
  • 指定像Domain=www.example.com这样的cookie属性将关闭www4.example.com的路径

PS: Domain属性中的尾随逗号会导致用户代理忽略属性=(

小开

之前的答案有点过时了。

RFC 6265发布于2011年，基于当时的浏览器共识。 从那时起，公共后缀域名就出现了一些复杂情况。我已经写了一篇文章来解释当前的情况——http://bayou.io/draft/cookie.domain.html

综上所述，cookie域的规则如下:

  • cookie的源域是原始请求的域。

  • 如果源域是IP，则cookie的domain属性不能设置。

  • 如果没有设置cookie的domain属性，则该cookie只适用于其源域。

  • 如果设置了cookie的域属性，

    • cookie适用于该域及其所有子域;
    • cookie的域必须与源域相同，或者是源域的父域
    • cookie的域不能是TLD、公共后缀或公共后缀的父后缀。

可以推导出cookie总是适用于它的原始域。

cookie域不应该有前导点，就像.foo.com一样——简单地使用foo.com

举个例子，

  • x.y.z.com可以将cookie域设置为自己或父域——x.y.z.com， y.z.com， z.com。但不是com，它是一个公共后缀。
  • domain=y.z.com的cookie适用于y.z.com， x.y.z.com， a.x.y.z.com等。

公共后缀的例子——com， edu， uk， co.uk， blogspot.com， compute.amazonaws.com

小开

2019年，我在最新的Chrome、Firefox和Safari中测试了所有的保护套。

回复新增:

  • 用于。example.com的cookie可以用于www.example.com吗?是的
  • example.com的cookie是否可用于example.com?是的
  • example.com的cookie可以用于www.example.com吗?没有，没有通配符的域只匹配自身。
  • example.com的cookie是否可用于anotherexample.com?没有
  • www.example.com可以为example.com设置cookie吗?没有，它将能够为'.example.com'设置cookie，但不能为'example.com'设置cookie。
  • www.example.com是否可以为www2.example.com设置cookie ?没有。但它可以为。example.com设置cookie, www2.example.com可以访问。
  • www.example.com是否可以为。com设置cookie ?没有

提交答案