我知道cookie是如何工作的，刚开始挖掘Codeigniter为什么不在SESSION中存储生成的csrf令牌，它只是存储在cookie中。关注安全性，我开始考虑php setcookie（）函数参数，例如path和domain。我问自己是否有可能从另一个域名'www.evilsite.com'中设置'evil_cookie'和一个path ='/'和domain ='www.goodsite.com'？另一个问题是，在向www.goodsite.com提出请求时，'evil_cookie'会被发送到'www.goodsite.com'吗？
所以，我做了一个测试。我创建了'set_cookie.php'文件并将其上传到某些'www.evilsite.com'：
setcookie('evil_cookie', 'gotcha', time() + 60 * 30, '/', 'www.goodsite.com');
我使用Firefox和Firebug + Cookie插件查看已发送和已接收的Cookie。所以，在收到'www.evilsite.com/set_cookie.php'的请求后，我确实收到了'evil_cookie'。但是，cookie没有保存（至少在firebug cookie插件面板中查看时没有这样的cookie）。也没有在再次请求“www.evilsite.com/set_cookie.php”时发送。刚收到但未保存。
从Firefox浏览器的角度来看，仅为当前域保存cookie是合乎逻辑且安全的。恕我直言，那些设置cookie（）参数如路径和域主要用于管理当前域及其子域的cookie，但不用于外部域。我有点不高兴我无法在php.net找到相关信息，所以我不确定它是否与浏览器相关，并且具体说明它如何处理“第三方cookie”或者它更像是标准？所有浏览器的行为是否相同？如果有任何可靠的来源，请分享。
这也与cookie的另一种使用相关 - 存储会话数据（不使用PHP本机会话，例如Codeigniter这样做）。因此，如果所有浏览器都不允许使用当前域以外的安全cookie，则可以。但是，它不能保护CSRF，因为'www.evilsite.com'可能包含恶意的javascript代码，当用户执行并从'www.evilsite.com'获取请求时，该代码将直接在客户端上创建'evil_cookie'。 / p>
答案 0 :(得分：3)
Cookie受same origin policy的约束：网站只能为自己的域撰写和读取Cookie。
答案 1 :(得分：2)
Cookie只能为当前域或其子域设置，因为您已经发现了（否则，任何人都可以替换其他人的cookie;随之而来的是混乱）。这是由浏览器强制执行的：如果您尝试从服务器端为另一个域设置cookie（使用HTTP标头），浏览器将忽略该cookie。如果您尝试从客户端（使用Javascript）执行相同操作，same origin policy将阻止您这样做。
因此，www.evilsite.com可以使用Javascript为自己的域设置cookie，但这不是问题：它可以使用HTTP标头来实现。这里没有新的攻击媒介。
答案 2 :(得分：1)
[...]是否有可能使用来自其他域名的路径='/'和domain ='www.goodsite.com'设置'evil_cookie'，来自某些'www.evilsite.com'？
不，用户代理应忽略 Set-Cookie 指令，其 Domain 属性不是domain-match当前请求的域：
除非Domain属性，否则用户代理将拒绝cookie 指定包含原点的cookie的范围 服务器。例如，用户代理将接受带有的cookie 来自“example.com”或“foo.example.com”的域属性 foo.example.com，但用户代理不接受带有的cookie “bar.example.com”或“baz.foo.example.com”的域属性。
用户代理甚至不接受此类cookie。类似的情况适用于 Path 和 Secure 属性。
另请参阅How do browser cookie domains work?，了解用户代理如何解释 Domain 属性值的示例。