How browsers know what cookies to send to server w

问题:

I know how the cookies work, just started to dig why Codeigniter does not store generated csrf token in SESSION, it just store in cookie. Concerned about security, I'v started to think about php setcookie() function params such as path and domain. And I have asked myself is it possible to set 'evil_cookie' with a path='/' and domain = 'www.goodsite.com' from another domain, from some 'www.evilsite.com'? And another question is, will 'evil_cookie' be sent to 'www.goodsite.com' when performing request to 'www.goodsite.com'?

So, I did a test. I'v created 'set_cookie.php' file and uploaded it to some 'www.evilsite.com':

setcookie('evil_cookie', 'gotcha', time() + 60 * 30, '/', 'www.goodsite.com');

I was using Firefox and Firebug + Cookie plugins for viewing sent and received cookies. So, I did receive 'evil_cookie' after the request to 'www.evilsite.com/set_cookie.php'. However, the cookie was not saved (at least there was no such cookie when viewing in firebug cookie plugin panel). Nor it was sent when requesting again to "www.evilsite.com/set_cookie.php". Just received but not saved.

From the Firefox browser point of view, it's logical and secure to save cookie for current domain only. IMHO those set cookie() params such as path and domain are primarily for managing cookies for current domain and its subdomains but not for external domains. I was a little bit upset I was unable to find related info on php.net, so I'm not sure is it a browser related behavior and specifics how it deals with "3rd party cookies" or it's more a standard? Does all browsers behave the same? If there's any solid and reliable source for such statements please share.

That is also relevant to another use of cookies - store session data (without using PHP native sessions, for example Codeigniter does so). So, if all browsers do not allow to safe cookie with other than current domain then It's OK. However, it does not protect from CSRF as 'www.evilsite.com' might contain evil javascript code that will create 'evil_cookie' directly on the client when a user will perform and get a request from 'www.evilsite.com'.

回答1:

[…] is it possible to set 'evil_cookie' with a path='/' and domain = 'www.goodsite.com' from another domain, from some 'www.evilsite.com'?

No, user agents should ignore Set-Cookie directives with Domain attributes that do not domain-match the current requested domain:

The user agent will reject cookies unless the Domain attribute specifies a scope for the cookie that would include the origin server. For example, the user agent will accept a cookie with a Domain attribute of "example.com" or of "foo.example.com" from foo.example.com, but the user agent will not accept a cookie with a Domain attribute of "bar.example.com" or of "baz.foo.example.com".

Such cookies would not even be accepted by user agents. Similar applies to the Path and Secure attributes.

See also How do browser cookie domains work? for examples of how the Domain attribute values are interpreted by user agents.

回答2:

Cookies are subject to the same origin policy: a site can only write and read cookies for its own domain.

回答3:

Cookies can only be set for the current domain or its subdomains as you have alredy found out (otherwise, anyone could replace anyone else's cookie; chaos would ensue). This is enforced by the browser: if you attempt to set cookies for another domain from the server side (using an HTTP header) the browser will ignore the cookie. If you attempt to do the same from the client side (using Javascript), the same origin policy will prevent you from doing so.

Therefore, www.evilsite.com can set a cookie for its own domain with Javascript, but that's not an issue: it could already do that using an HTTP header. There's no new attack vector here.