Я знаю, как работают куки, просто начал копать, почему Codeigniter не хранит сгенерированный токен csrf в SESSION, он просто хранится в cookie. Обеспокоенный безопасностью, я начал думать о параметрах функции php setcookie (), таких как путь и домен. И я спросил себя, можно ли установить «evil_cookie» с путём = '/' и 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 для просмотра отправленных и полученных файлов cookie. Итак, я получил «evil_cookie» после запроса «www.evilsite.com/set_cookie.php». Однако файл cookie не был сохранен (по крайней мере, не было такого файла cookie при просмотре в панели плагинов cookie firebug). Также он не был отправлен при повторном обращении к «www.evilsite.com/set_cookie.php». Только что получил, но не спасен.
С точки зрения браузера Firefox логично и безопасно сохранять cookie только для текущего домена. IMHO те, которые задают параметры cookie (), такие как путь и домен, предназначены главным образом для управления кукисами для текущего домена и его поддоменов, но не для внешних доменов. Я был немного расстроен, я не смог найти связанную с ним информацию на php.net , поэтому я не уверен, что это поведение, связанное с браузером, и определяет, как он относится к «сторонним куки» или это скорее стандарт? Все ли браузеры ведут себя одинаково? Если есть какие-либо надежные и надежные источники для таких заявлений, пожалуйста, поделитесь ими.
Это также относится к другому использованию файлов cookie – хранить данные сеанса (без использования собственных сессий PHP, например Codeigniter). Итак, если все браузеры не позволяют безопасно хранить файлы cookie, кроме текущего домена, тогда все в порядке. Однако он не защищает от CSRF, поскольку «www.evilsite.com» может содержать злой код javascript, который будет создавать «evil_cookie» непосредственно на клиенте, когда пользователь выполнит запрос и получит запрос от «www.evilsite.com».
[…] можно ли установить «evil_cookie» с помощью пути = '/' и domain = 'www.goodsite.com' из другого домена, с некоторого «www.evilsite.com»?
Нет, пользовательские агенты должны игнорировать директивы Set-Cookie с атрибутами домена, которые не соответствуют домену текущего запрашиваемого домена:
Пользовательский агент отклонит файлы cookie, если атрибут Domain не указывает область для файла cookie, который будет включать исходный сервер. Например, пользовательский агент принимает cookie с атрибутом домена «example.com» или «foo.example.com» из файла foo.example.com, но агент пользователя не принимает cookie с атрибутом Domain «bar.example.com» или «baz.foo.example.com».
Такие файлы cookie даже не будут приняты пользовательскими агентами. Аналогично относится к атрибутам Path и Secure .
См. Также Как работать с доменами cookie браузера? примеры того, как значения атрибутов домена интерпретируются агентами пользователя.
Куки-файлы подчиняются одной и той же политике происхождения : сайт может только писать и читать файлы cookie для своего собственного домена.
Куки-файлы могут быть установлены только для текущего домена или его поддоменов, как вы узнали об этом (в противном случае любой может заменить чей-то куки-файл, возникнет хаос). Это обеспечивается браузером: если вы пытаетесь установить файлы cookie для другого домена со стороны сервера (используя HTTP-заголовок), браузер будет игнорировать файл cookie. Если вы попытаетесь сделать то же самое с клиентской стороны (используя Javascript), такая же политика происхождения не позволит вам это сделать.
Поэтому http://www.evilsite.com может установить cookie для своего домена с помощью Javascript, но это не проблема: он уже может это сделать с помощью HTTP-заголовка. Здесь нет нового вектора атаки.