Cookie的域属性是否已发送回服务器？

Question

如果evil.example.com设置一个域属性设置为.example.com的cookie,则浏览器会在foo.example.com的请求中包含此cookie.

Tangled Web指出,对于foo.example.com,此类cookie与foo.example.com设置的cookie几乎没有区别.但是根据RFC,cookie的domain属性应该发送到服务器,这样foo.example.com就可以区分并拒绝evil.example.com设置的cookie.

当前浏览器实现的状态是什么？域名是否通过cookie发回？

Answer 1

RFC 2109和RFC 2965是标准化cookie处理的历史尝试.不幸的是,它们与浏览器的实际操作没有任何相似之处,应该完全被忽略.

真实世界的行为主要是由原始的Netscape cookie_spec定义的,但这作为一个规范非常不足,导致了一系列的浏览器差异 -

• 接受的日期格式;
• 如何在多个匹配时处理具有相同名称的cookie;
• 非ASCII字符如何工作(或不工作);
• 报价/逃逸;
• 如何进行域匹配.

RFC 6265试图清理这些混乱并明确地编写浏览器应该做的目标.它并不是说浏览器应该发送domain或者path,因为历史上没有浏览器曾经这样做过.

因为您无法检测到cookie来自父级domain(*),所以您必须小心使用您的主机名以避免重叠域,如果您想将cookie分开 - 特别是对于IE,即使您不这样做设置domain,设置的cookie example.com将始终继承foo.example.com.

因此:如果您认为将来可能想要一个具有单独cookie的子域(不应该从其父级读取敏感cookie),请不要为您的站点使用"no-www"主机名; 如果您确实需要一个完全独立的cookie上下文,以防止evil.example.com将cookie值注入其他example.com站点,那么您别无选择,只能使用完全独立的域名.

对某些攻击模型可能有效的替代方法是签署您生成的每个cookie值,例如使用HMAC.

*:有一种方式.尝试删除具有相同的饼干domain,并path设置为你想要的饼干.如果cookie在你这样做时消失了,那么它必须有这些domain和path设置,所以原来的cookie是好的.如果那里还有一个cookie,它来自其他地方你可以忽略它.这样做不方便,没有JavaScript是不切实际的,也不是不漏水的,因为原则上攻击者可能会同时删除他们注入的cookie.