Спустя месяц после публикации RFC1945, в феврале 1997 года выходит в свет спецификация RFC2109, в которой описывается механизм управления состоянием для HTTP протокола, или проще говоря, она вводит всем известные Cookies. Теперь протокол имеет постоянное соединение и состояние, а версию HTTP/1.0 с этих пор можно называть connectionless и stateless.

Впервые Cookies появились в браузере Netscape Navigator в 1994 году, поэтому не удивительно, что одним из авторов спецификации был разработчик из Netscape Communications, Лу Монтули. Кстати Лу на тот момент было всего 23 года, и он также являлся одним из авторов браузера Lynx.

В феврале 1997 года появилась спецификация RFC2109. Она вводила два дополнительных HTTP заголовка Cookie и Set-Cookie, которые помогали обмениваться информацией о состоянии между клиентом и сервером. Также спецификация описывала их синтаксис, вводила лимиты на количество сохраняемых значений Cookies и их размер (4kb), описывала возможные проблемы передачи заголовков через proxy-сервера.

С помощью Cookies можно было имплементировать пользовательские сессии или реализовать какую-то персонализацию, то есть хранить некоторые значения, от которых будет зависеть поведение или интерфейс веб-страницы.

Однако существовали некоторые концептуальные недостатки, о которых прямым текстом заявляется еще в самой первой версии спецификации. Например, вопрос безопасности: любая информация может стать доступной для злоумышленников; любой злоумышленник-посредник может изменить Cookies по мере их продвижения по сети; злоумышленник может напрямую подделать значение Cookies, организовать спуфинг.

Чтобы хоть как-то обезопасить себя от этих проблем, спецификация описывает аттрибут Secure, Cookies в таком случае отсылаются на сервер только тогда, когда запрос отправляется через HTTPS протокол.

Развитие технологии и новые проблемы

Следующая версия спецификации RFC2965, вышедшая в октябре 2000, ввела дополнительные заголовки Cookie2 и Set-Cookie2, а спецификация RFC6265 2011 года эти заголовки с двойкой на конце переводит в статус obsolete, то есть с этого момента эти заголовки не должны использоваться. Сейчас спустя десятилетие возникает вопрос, что это было?

Функционально заголовок Set-Cookie2 позволял ограничить использование Cookies для указанного списка портов. RFC2965 принуждала поддерживать одновременно два синтаксиса, которые некоторые браузеры не реализовывали полноценно, что откровенно бесило некоторых разработчиков. По итогу все вернулись к использованию одного имени, прежних двух заголовков.

Напомню, что страницы могут включать в себя ресурсы, находящиеся на отличных доменах от домена текущей страницы, соответственно HTTP-запросы к ним могут также содержать свои Cookies, и это не говоря о том, что запросы можно слать напрямую с помощью JavaScript. Такие запросы называются межсайтовые, а Cookies в запросах Third-Party Cookies. И вся эта ситуация порождает ряд новых проблем.

Например, если злоумышленник встроит вредоносный код в веб-страницу, то даже описанный выше аттрибут Secure не убережет от воровства Cookies. Для решения этой проблемы в RFC6265 от 2011 года был введен аттрибут httpOnly, который предотвращал доступ к document.cookie из JavaScript.

Так называемый межсайтовый скриптинг может привести к уязвимости CSRF, при которой будут использованы Cookies пользователя. Эту проблему решили с помощью другого аттрибуту — SameSite, он описан в новом черновике спецификации rfc6265bis, работа над которым ведется с октября 2017 года.

Существуют и другие проблемы, например, приватность и трекинг пользователей и прочие, каждая из которых имеет свое развитие и свои варианты решений. Так или иначе, вы стали свидетелем того, как безобидные дополнительные 4kb в HTTP-заголовках впоследствии привели к немалому числу сложностей.

Сопроводительные материалы

— The magic cookie: How Lou Montully cured the Web’s Amnesia
— MDN. HTTP Cookies
— Steal Cookies with Reflected XSS
— SameSite cookies explained