Как файлы cookie передаются из браузера на сервер

Обновлено: 05.07.2024

Цель

Файлы cookie используются веб-серверами для различения пользователей и работы в зависимости от пользователя. Файлы cookie были изобретены для реализации виртуальной корзины покупок: это виртуальное устройство, в котором пользователь может «размещать» товары для покупки, чтобы пользователи могли перемещаться по сайту, где отображаются товары, добавляя или удаляя товары из корзины покупок в любое время. . Файлы cookie позволяют содержимому корзины зависеть от действий пользователя.

Реализация

Заблуждения

Миф. Файлы cookie похожи на червей и вирусы в том смысле, что они могут стирать данные с жестких дисков пользователя.
Миф. Файлы cookie — это разновидность шпионского ПО, поскольку они могут считывать личную информацию, хранящуюся на компьютере пользователя.
Миф. Файлы cookie создают всплывающие окна.
Миф. Файлы cookie используются для рассылки спама.
Миф. Файлы cookie используются только для рекламы.

Настройки браузера

Неточная идентификация

Кража файлов cookie

Межсайтовый скриптинг: файл cookie, которым должны обмениваться только сервер и клиент, отправляется другой стороне.

Отравление файлами cookie: злоумышленник отправляет на сервер недопустимый файл cookie, возможно, изменяя действительный файл cookie, ранее полученный от сервера.

Отравление файлами cookie

Однако большинство веб-сайтов сохраняют только идентификатор сеанса — случайно сгенерированное уникальное число, используемое для идентификации сеанса пользователя, — в самом файле cookie, тогда как вся остальная информация хранится на сервере. В этом случае проблема отравления куки в значительной степени устраняется.

Приготовление еды на месте

IP-адрес

Отслеживание по IP-адресу может быть невозможно в некоторых системах, которые используются для сохранения анонимности в Интернете, таких как Tor. В таких системах один браузер может не только передавать несколько адресов в течение сеанса, но и может показаться, что несколько пользователей заходят с одного и того же IP-адреса, что делает использование IP-адреса для отслеживания совершенно ненадежным.

Некоторые крупные интернет-провайдеры, в том числе AOL, направляют весь веб-трафик через небольшое количество прокси-серверов, что делает эту схему особенно неработоспособной.

URL (строка запроса)

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

Постоянство на стороне клиента

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

Если JavaScript включен, свойство window.name окна объекта может использоваться для постоянного хранения данных. Это свойство остается неизменным при загрузке и выгрузке других веб-страниц. Этот взлом малоизвестен и поэтому не считается угрозой безопасности. Кроме того, имя_окна создает проблемы совместимости браузеров, поскольку браузеры на основе Mozilla, такие как Mozilla Firefox, не поддерживают сохраняемость JavaScript с использованием имени окна.

История

Файлы cookie в основном используются для трех целей:

Логин, корзина, счет в игре или что-то еще, что сервер должен помнить

Пользовательские настройки, темы и другие настройки

Запись и анализ поведения пользователей

Когда-то файлы cookie использовались для общего хранения данных на стороне клиента. Хотя это имело смысл, когда они были единственным способом хранения данных на клиенте, теперь рекомендуются современные API-интерфейсы хранилища. Файлы cookie отправляются с каждым запросом, поэтому они могут снизить производительность (особенно для мобильных подключений для передачи данных). Современные API для клиентского хранилища — это API веб-хранилища ( localStorage и sessionStorage ) и IndexedDB.

Заголовки Set-Cookie и Cookie

Примечание. Вот как использовать заголовок Set-Cookie в различных серверных приложениях:

Определить время жизни файла cookie

Срок жизни файла cookie можно определить двумя способами:

Примечание. Когда вы устанавливаете дату и время истечения срока действия, они относятся к клиенту, на котором устанавливается файл cookie, а не к серверу.

Вот пример:

Атрибут домена

Атрибут домена указывает, какие хосты могут получать файлы cookie. Если атрибут не указан, по умолчанию используется тот же хост, который установил файл cookie, за исключением поддоменов. Если указан домен , субдомены всегда включаются. Следовательно, указание Домена менее ограничительно, чем его отсутствие. Однако это может быть полезно, когда поддоменам необходимо обмениваться информацией о пользователе.

Атрибут пути

Атрибут Path указывает путь URL-адреса, который должен существовать в запрошенном URL-адресе для отправки заголовка Cookie. Символ %x2F ("/") считается разделителем каталогов, и подкаталоги также совпадают.

Например, если вы зададите Path=/docs , эти пути запросов будут совпадать:

Но эти пути запросов не:

Атрибут того же сайта

Вот пример:

Префиксы файлов cookie

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

Уязвимое приложение в субдомене может установить файл cookie с атрибутом Домен, который дает доступ к этому файлу cookie во всех других субдоменах. Этим механизмом можно злоупотреблять при атаке фиксации сеанса. См. раздел «Фиксация сеанса», чтобы узнать об основных методах устранения неполадок.

Однако в качестве меры глубокой защиты вы можете использовать префиксы файлов cookie для утверждения определенных фактов о файлах cookie. Доступны два префикса:

Если имя файла cookie имеет этот префикс, оно принимается в заголовке Set-Cookie только в том случае, если оно помечено атрибутом Secure и было отправлено из безопасного источника. Это слабее, чем префикс __Host-.

Примечание. На сервере приложений веб-приложение должно проверять полное имя файла cookie, включая префикс. Пользовательские агенты не удаляют префикс из файла cookie перед его отправкой в заголовке файла cookie запроса.

Дополнительную информацию о префиксах файлов cookie и текущем состоянии поддержки браузеров см. в разделе «Префиксы» справочной статьи Set-Cookie.

Доступ к JavaScript с помощью Document.cookie

Обратите внимание на вопросы безопасности в разделе «Безопасность» ниже. Файлы cookie, доступные для JavaScript, могут быть украдены с помощью XSS.

Безопасность

Отслеживание и конфиденциальность

Правила использования файлов cookie

Общее положение о конфиденциальности данных (GDPR) в Европейском Союзе
Директива ЕС об электронной конфиденциальности
Закон штата Калифорния о конфиденциальности потребителей

Эти правила действуют во всем мире. Они применяются к любому сайту в Всемирной сети, к которому имеют доступ пользователи из этих юрисдикций (ЕС и Калифорния, с оговоркой, что закон Калифорнии применяется только к организациям с валовым доходом более 25 млн долларов США, в том числе). .

Эти правила включают такие требования, как:

Другие способы хранения информации в браузере

Назад и вперед

Каждый файл cookie отделяется запятой , а атрибуты каждого файла cookie разделяются точкой с запятой ; . Требуются два значения: первая пара имя=значение, которая всегда является строковым значением. Остальные атрибуты, задающие другие параметры файла cookie, являются необязательными и задают другие параметры файла cookie.

Чтобы отправить файл cookie обратно на сервер, браузер использует заголовок файла cookie:

Хотя многие языки программирования и фреймворки абстрагируют от вас синтаксический анализ и создание этих заголовков файлов cookie (Crystal, Ruby, PHP, Phoenix, Node.js, Python), иногда полезно знать, как все это работает за кулисами. .

Срок действия и удаление

Чтобы удалить файл cookie, необходимо установить дату истечения срока его действия в прошлом. Это будет сигналом для браузера о том, что файл cookie следует удалить. Для чистоты также рекомендуется установить его значение в пустую строку.

Другие вкусности

Файлы cookie имеют несколько других интересных атрибутов, которые используются для ограничения или разрешения их использования в определенных местах:

Я не буду подробно описывать все это. Подробнее о них можно прочитать на веб-ресурсе Mozilla.

Здесь также не рассматривается максимальный объем данных, которые вы можете хранить в файле cookie. По большей части вы можете предположить, что у вас все в порядке, если у вас меньше 4k данных. На практике все сложнее.

Сеансы

Одним из распространенных способов является использование значения файла cookie для сохранения сеанса:

Теперь приложение может просматривать файл cookie с именем _myapp_session , читать и анализировать JSON и использовать его для таких вещей, как установка current_user в запросе.Тем не менее, описанный выше метод чрезвычайно легко взломать. Это просто текст!

Заблокировать

Хороший сеанс зашифрован. Более реальный пример:

Вот как сеансы работают в Lucky. Сеанс будет файлом cookie с именем вроде _myapp_session. Значение файла cookie — это зашифрованная строка JSON, которую может расшифровать только сервер с сеансовым ключом. Хранение его в формате JSON позволяет нам иметь ключ/значение, подобное store, но с использованием одного файла cookie вместо нескольких.

Существуют и другие способы хранения данных сеанса, например хранилище "ключ-значение", например Redis. Но даже для этого требуется файл cookie, чтобы определить, какие значения нужно получить.

Примечание о Flash

Вспышка – это одноразовое сообщение, отображаемое пользователю после того, как он что-то сделал. Например, после входа в систему вы можете увидеть сообщение:

Если вы обновите страницу или перейдете в другое место, это сообщение исчезнет.

Быстрые сообщения хранятся как две отдельные части: сообщения для текущего запроса и сообщения для отображения при следующем запросе. Эти части называются now и next . В начале запроса существующие данные считываются во внутренний хэш now, который считывается и отображается пользователю.

Когда флэш-память устанавливается во время цикла запроса/ответа, она сохраняется во внутреннем хеше next. На этапе ответа next конвертируется в JSON и сохраняется в сессии. Во время следующего запроса next считывается и цикл продолжается.

Вам повезло?

Это только начало того, что нового в последней версии Lucky. Ознакомьтесь с Lucky Framework, если вы хотите поиграть с любой из этих концепций или просто попробовать новый фреймворк!

Если вам понравился этот пост, вам также могут понравиться:

Обновите кодовую базу с помощью аудита кода

Узнайте, как мы можем помочь вам понять текущее состояние качества вашего кода, сократить время доставки, повысить удовлетворенность разработчиков и повысить удобство работы пользователей

Крис Койсигава

Вы когда-нибудь задумывались, как можно один раз войти на веб-сайт и оставаться в нем, даже если вы закроете браузер? Или добавили товар в корзину без входа в систему?

HTTP, или протокол передачи гипертекста, — это протокол без сохранения состояния. Согласно Википедии, это протокол без сохранения состояния, поскольку он «не требует, чтобы HTTP-сервер сохранял информацию или статус о каждом пользователе в течение нескольких запросов».

Вы все еще можете видеть это сегодня на простых веб-сайтах: вы вводите URL-адрес браузера, браузер отправляет запрос куда-то на сервер, и сервер возвращает файлы для отображения страницы, и соединение закрывается.

Теперь представьте, что вам нужно войти на веб-сайт, чтобы увидеть определенный контент, например, в LinkedIn. Процесс в основном такой же, как и описанный выше, но вам предоставляется форма для ввода вашего адреса электронной почты и пароля.

Вы вводите эту информацию, и ваш браузер отправляет ее на сервер. Сервер проверяет вашу регистрационную информацию и, если все в порядке, отправляет данные, необходимые для отображения страницы, обратно в ваш браузер.

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

Это было бы очень неприятно, не так ли? Многие разработчики тоже так думали и нашли разные способы создания сеансов с отслеживанием состояния в Интернете.

Лу Монтулли, разработчик Netscape в начале 90-х годов, столкнулся с проблемой: он разрабатывал интернет-магазин для другой компании, MCI, которая должна была хранить товары из корзины каждого покупателя на своих серверах. Это означало, что людям нужно было сначала создать учетную запись, это было медленно и занимало много места в памяти.

MCI запросил, чтобы все эти данные хранились на собственном компьютере каждого клиента. Кроме того, они хотели, чтобы все работало так, чтобы клиентам не приходилось сначала входить в систему.

Чтобы решить эту проблему, Лу обратился к идее, которая уже была хорошо известна среди программистов: к волшебным файлам cookie.

Волшебный файл cookie или просто файл cookie – это фрагмент данных, который передается между двумя компьютерными программами. Они «магические», потому что данные в файле cookie часто являются случайным ключом или токеном и на самом деле предназначены только для программного обеспечения, которое их использует.

Лу взял концепцию волшебных файлов cookie и применил ее к интернет-магазину, а затем и к браузерам в целом.

Например, когда вы входите на веб-сайт, это похоже на процесс входа в парк развлечений. Сначала вы платите за билет, затем, когда вы входите в парк, персонал проверяет ваш билет и выдает вам браслет.

Это похоже на то, как вы входите в систему: сервер проверяет ваше имя пользователя и пароль, создает и сохраняет сеанс, генерирует уникальный идентификатор сеанса и отправляет обратно файл cookie с идентификатором сеанса.

(Обратите внимание, что идентификатор сеанса — это не ваш пароль, а нечто совершенно отдельное и сгенерированное на лету. Правильная обработка пароля и проверка подлинности выходит за рамки этой статьи, но вы можете найти некоторые подробные инструкции здесь.)

Пока вы находитесь в парке развлечений, вы можете прокатиться на любом аттракционе, предъявив браслет.

Аналогичным образом, когда вы отправляете запросы на веб-сайт, на который вы вошли, ваш браузер отправляет файл cookie с вашим идентификатором сеанса обратно на сервер. Сервер проверяет ваш сеанс, используя идентификатор сеанса, а затем возвращает данные для вашего запроса.

Наконец, после того, как вы покинете парк развлечений, ваш браслет перестанет работать — вы не сможете использовать его, чтобы вернуться в парк или покататься на других аттракционах.

Это похоже на выход из веб-сайта. Ваш браузер отправляет запрос на выход на сервер вместе с вашим файлом cookie, сервер удаляет ваш сеанс и сообщает вашему браузеру, что нужно удалить файл cookie с идентификатором сеанса.

Если вы хотите вернуться в парк развлечений, вам придется купить еще один билет и получить еще один браслет. Другими словами, если вы хотите продолжить использование веб-сайта, вам придется снова войти в систему.

Ограничения файлов cookie

< td>Емкость

Файлы cookie	Локальное хранилище	Хранение сеансов
4 КБ	10 МБ	5 МБ
Доступно из	Любое окно	Любое окно	Та же вкладка
Истекает	Установить вручную	Никогда	При закрытии вкладки
Место хранения	Браузер и сервер	Только браузер	Только браузер
Отправлено с запросами	Да	Нет	Нет

Как установить файл cookie в JavaScript

Вот как установить файл cookie в ванильном JavaScript:

Затем, когда вы откроете консоль разработчика, нажмите "Приложение", а затем на сайте в разделе "Файлы cookie" вы увидите только что добавленный файл cookie:

Если вы внимательно посмотрите на свой файл cookie, вы увидите, что срок его действия установлен на Session . Это означает, что файл cookie будет уничтожен, когда вы закроете вкладку или браузер.

Это может быть то поведение, которое вам нужно, например, для интернет-магазина с платежной информацией.

Но если вы хотите, чтобы ваш файл cookie хранился дольше, вам необходимо установить дату истечения срока действия.

Как установить срок действия файла cookie в JavaScript

Объект JavaScript Date должен сделать это намного проще и гибче. Подробнее об объекте Date можно прочитать здесь.

Или вы можете использовать атрибут max-age с количеством секунд, в течение которых вы хотите, чтобы ваш файл cookie сохранялся:

Затем, когда эта дата наступит, браузер автоматически удалит ваш файл cookie.

Как обновить файл cookie в JavaScript

Независимо от того, имеет ли ваш файл cookie срок действия, его легко обновить.

Просто измените значение файла cookie, и браузер автоматически подберет его:

Как указать путь для файла cookie в JavaScript

Иногда вам нужно, чтобы файл cookie работал только с определенными частями вашего веб-сайта. В зависимости от того, как настроен ваш веб-сайт, один из способов сделать это — использовать атрибут пути.

Вот как сделать так, чтобы файл cookie работал только на странице информации в /about :

Теперь ваш файл cookie будет работать только с /about и другими вложенными подкаталогами, такими как /about/team , но не с /blog .

Как удалить файл cookie в JavaScript

Чтобы удалить файл cookie в JavaScript, просто установите для атрибута expires дату, которая уже прошла:

Вы также можете использовать max-age и передать ему отрицательное значение:

Затем, когда вы проверите файл cookie, он исчезнет:

Тем не менее, есть несколько способов, которыми злоумышленник может украсть ваш файл cookie и использовать его, чтобы нанести ущерб.

Мы рассмотрим некоторые распространенные причины, по которым это может произойти, и рассмотрим различные способы решения этой проблемы.

Кроме того, обратите внимание, что все фрагменты кода будут на стандартном JavaScript. Если вы хотите внедрить эти исправления на сервере, вам нужно найти точный синтаксис для вашего языка или платформы.

Атаки «человек посередине»

Атака «человек посередине» (MitM) описывает широкую категорию атак, когда злоумышленник находится между клиентом и сервером и перехватывает данные, проходящие между ними.

Источник: атаки «человек посередине» и способы их предотвращения

Это можно сделать разными способами: получить доступ к незащищенному веб-сайту или прослушивать его, имитировать общедоступный маршрутизатор Wi-Fi, спуфинг DNS или с помощью вредоносного или рекламного ПО, такого как SuperFish.

Вот общий обзор атак MitM и того, как веб-сайты могут защитить себя и своих пользователей.

Предупреждение. В начале видео рассказывается о Марии, королеве Шотландии, и показано анимированное изображение ее обезглавливания. Это не слишком ужасно, но если вы хотите избежать этого, перейдите к этой метке времени:

XSS-атаки

Атака XSS (межсайтовый скриптинг) описывает категорию атак, когда злоумышленник внедряет непреднамеренный, потенциально опасный код на веб-сайт.

Эти атаки очень проблематичны, потому что они могут затронуть каждого посетителя сайта.

Например, если на сайте есть раздел комментариев и кто-то может добавить вредоносный код в качестве комментария, это может повлиять на всех, кто посещает сайт и читает этот комментарий.

Вот видео, в котором дается общий обзор различных типов XSS — отраженного, сохраненного, основанного на DOM и мутации:

Как разработчик, вы должны следить за тем, чтобы на вашем сервере применялась политика единого источника и чтобы все данные, которые вы получаете от людей, подвергались надлежащей очистке.

CSRF-атаки

Атака CSRF (подделка межсайтовых запросов) — это когда злоумышленник обманом заставляет человека выполнить непреднамеренное, потенциально вредоносное действие.

Например, если вы вошли на сайт и нажали ссылку в комментарии, если эта ссылка является частью атаки CSRF, это может привести к непреднамеренному изменению данных для входа или даже к удалению вашей учетной записи. .

Хотя CSRF-атаки в некоторой степени связаны с XSS-атаками, в частности, отраженными XSS-атаками, когда кто-то вставляет вредоносный код на сайт, каждая из них использует разные типы доверия.

Согласно Википедии, в то время как XSS «использует доверие пользователя к определенному сайту, CSRF использует доверие, которое сайт имеет к браузеру пользователя».

Вот видео, объясняющее основы CSRF и дающее несколько полезных примеров:

Для SameSite можно задать несколько значений:

Основные браузеры обрабатывают SameSite немного по-разному. Например, если SameSite не задан для файла cookie, Google Chrome по умолчанию устанавливает для него значение Lax.

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

Чтобы еще больше замутить воду, поставщики аутентификации как услуги, такие как Auth0, позволяют выполнять оба типа аутентификации.

Если вы хотите узнать больше о веб-токенах и аутентификации на основе токенов, ознакомьтесь с некоторыми из наших статей здесь.

Когда вы предоставляете разработчику файл cookie

Читайте также: