Я знаю, как работают куки, только начал копать, почему Codeigniter не хранит сгенерированный токен csrf в SESSION, он просто хранит в куки.Заботясь о безопасности, я начал думать о параметрах функции php setcookie (), таких как путь и домен.И я спросил себя, возможно ли установить 'evil_cookie' с путем = '/' и доменом = '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 для просмотра отправленных и полученных файлов cookie.Итак, я получил «evil_cookie» после запроса к «www.evilsite.com/set_cookie.php».Однако файл cookie не был сохранен (по крайней мере, такого файла не было при просмотре в панели плагина cookie-файла firebug).Также оно не было отправлено при повторном запросе на «www.evilsite.com/set_cookie.php».Только что получил, но не сохранил.
С точки зрения браузера Firefox логично и безопасно сохранять cookie только для текущего домена.ИМХО эти установленные параметры cookie (), такие как путь и домен, в основном предназначены для управления файлами cookie для текущего домена и его поддоменов, но не для внешних доменов.Я был немного расстроен. Мне не удалось найти соответствующую информацию на php.net , поэтому я не уверен, что это поведение, связанное с браузером, и особенности того, как он работает с «сторонними файлами cookie», или это большестандарт?Все ли браузеры ведут себя одинаково?Если есть какой-либо надежный и надежный источник для таких заявлений, пожалуйста, поделитесь.
Это также относится к другому использованию файлов cookie - хранению данных сеанса (без использования собственных сеансов PHP, например, Codeigniter делает это).Таким образом, если все браузеры не разрешают сохранять куки с другим доменом, то все в порядке.Однако он не защищает от CSRF, поскольку «www.evilsite.com» может содержать злой код JavaScript, который создаст «evil_cookie» непосредственно на клиенте, когда пользователь выполнит запрос и получит запрос от «www.evilsite.com».