Как браузеры узнают, какие cookies отправлять серверу при запросе?

Я знаю, как работают куки, просто начал копать, почему Codeigniter не хранит сгенерированный токен csrf в SESSION, он просто хранится в куках. Заботясь о безопасности, я начал думать о параметрах функции php setcookie(), таких как путь и домен. И я спросил себя, можно ли установить 'evil_cookie' с path='/' и domain = 'www.goodsite.com' из другого домена, из какого-нибудь 'www.evilsite.com'? И еще вопрос, будет ли 'evil_cookie' отправляться на 'www.goodsite.com' при выполнении запроса на 'www.goodsite.com'?

Итак, я провел тест. Я создал файл 'set_cookie.php' и загрузил его на какой-нибудь 'www.evilsite.com':

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

Я использовал Firefox и Firebug + плагины Cookie для просмотра отправленных и полученных cookies. Итак, я действительно получил 'evil_cookie' после запроса к 'www.evilsite.com/set_cookie.php'. Однако куки не были сохранены (по крайней мере, их не было при просмотре в панели плагина firebug cookie). Не был он отправлен и при повторном запросе к "www.evilsite.com/set_cookie.php". Только получен, но не сохранен.

С точки зрения браузера Firefox, логично и безопасно сохранять cookie только для текущего домена. IMHO те установленные параметры cookie(), такие как path и domain, предназначены в первую очередь для управления cookie для текущего домена и его поддоменов, но не для внешних доменов. Я был немного расстроен, что не смог найти соответствующую информацию на php.net, поэтому я не уверен, является ли это поведением браузера и спецификой его работы с "сторонними куками" или это больше стандарт? Все ли браузеры ведут себя одинаково? Если есть какой-либо надежный и достоверный источник для таких утверждений, пожалуйста, поделитесь.

Это также относится к другому использованию cookies - хранению данных сессии (без использования нативных сессий PHP, например, Codeigniter делает это). Таким образом, если все браузеры не позволяют сохранять cookie с доменом, отличным от текущего, то все в порядке. Однако, это не защищает от CSRF, так как 'www.evilsite.com' может содержать злой javascript код, который создаст 'evil_cookie' прямо на клиенте, когда пользователь выполнит и получит запрос от 'www.evilsite.com'.