Cookie-файлы и как их готовить: зачем они нужны, чем опасны и при чем тут session hijacking

Практически на любом веб-сайте пользователю предлагают принять, отклонить или настроить собираемые cookie-файлы, а иногда его просто предупреждают об использовании куки по умолчанию. Мы просмотрели 647 веб-сайтов, выбранных случайным образом: на 563 из них отображались оповещения о cookie-файлах. При этом зачастую пользователи не задумываются, что на самом деле скрывается за баннером, который просит их подтвердить или отклонить сбор куки.

Сайты стали предупреждать об использовании cookie-файлов после внедрения нормативно-правовых документов, регулирующих сбор пользовательской информации и защиту персональных данных, например GDPR. При помощи настроек куки пользователь может минимизировать объем собираемой информации о своей активности в интернете. Например, отклонить сбор и хранение сторонних куки, которые зачастую не влияют на функционирование сайта, а используются в маркетинговых и аналитических целях. В этой статье мы разберемся, что такое cookie-файлы, какие они бывают, как работают и почему об их наличии необходимо предупреждать. Также мы расскажем про чувствительные куки с идентификатором Session ID, виды атак на них и способы защиты для разработчиков сайтов и пользователей.

Что такое браузерные cookie-файлы

Cookie-файлы — это текстовые файлы с фрагментами данных, которые веб-сервер отправляет браузеру при посещении сайта. Браузер сохраняет эти данные на устройстве пользователя и отправляет их обратно на сервер при каждом последующем запросе к сайту. Таким образом происходит идентификация пользователя и оптимизация его взаимодействия с сайтом.

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

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

Для идентификации пользователя сайтом и упрощения авторизации собираются такие данные, как логин и пароль, токены безопасности. Хотя эту информацию не рекомендуется хранить в cookie-файлах, в отдельных случаях она может там оказаться, например, если активировать флаг «Запомнить меня». Токены безопасности становятся уязвимыми, если их помещают в куки, доступные JS-скриптам.

Еще одним важным типом информации, которая хранится в cookie-файлах и может стать очень опасной в руках злоумышленников, является идентификатор сеанса (Session ID) — уникальный код, присваиваемый пользователю при входе на сайт. Именно он становится основной целью атак типа session hijacking и позволяет злоумышленнику «подменить» пользователя. Далее мы подробно рассмотрим этот вид атак. Примечательно, что Session ID может как храниться в cookie-файлах, так и прописываться прямо в URL-адресе страницы, если пользователь отключил куки.

Пример Session ID в cookie-файлах в панели разработчика браузера (Firefox)

Пример Session ID в URL-адресе: example.org/?account.php?osCsid=dawnodpasb<...>abdisoa.

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

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

Основные виды cookie-файлов

Классификация cookie-файлов по времени хранения

По сроку хранения cookie-файлы можно разделить на временные и постоянные.

Временные (сессионные) куки используются в момент посещения сайта и удаляются после его закрытия. Они нужны, например, чтобы пользователю не приходилось каждый раз вводить учетные данные при переходе между страницами одного сайта, а также заново выставлять настройки языка или региона. В рамках одного сеанса эти значения будут сохраняться в cookie-файл, чтобы обеспечивать бесперебойный доступ в личный кабинет и корректную работу функций сайта для зарегистрированных пользователей. К временным cookie-файлам также относятся, например, записи в формах заказов и данные о посещаемых страницах (эта информация может попасть и в постоянные куки, если пользователь установит флаг «Запомнить мой выбор» или «Сохранить параметры»). При этом стоит отметить, что временные куки не удаляются, если в браузере включено автоматическое сохранение сеанса пользователя (то есть загрузка ранее открытых вкладок) — система будет считать все обращения к сайту одним и тем же сеансом.

Постоянные cookie-файлы, в отличие от временных, сохраняются даже после того, как пользователь покинул сайт. Срок их хранения устанавливается владельцем сайта (обычно около года), но они могут быть удалены в любое время, если пользователь решит очистить куки в настройках браузера. В постоянных cookie-файлах хранятся логины, пароли, номера телефонов, адреса, платежные реквизиты. Также они используются в рекламных целях для определения предпочтений пользователя. В cookie-файлах, которые содержат конфиденциальную информацию, указывается атрибут HttpOnly, благодаря которому браузер не может получить их содержимое, — при любом открытии сайта файлы сразу отправляются на веб-сервер.

Примечательно, что в зависимости от действий пользователя на сайте учетные данные могут попасть как во временные, так и в постоянные куки. Например, во время навигации по страницам в рамках одной сессии логин и пароль сохраняются во временных cookie-файлах, а если пользователь поставит галочку «Запомнить меня» — в постоянных.

Классификация cookie-файлов по источнику

По своему происхождению cookie-файлы делятся на собственные (first-party) и сторонние (third-party). Первые генерируются самим сайтом, вторые — сторонними ресурсами. Рассмотрим эти виды подробнее.

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

Сторонние куки — файлы, использующиеся прочими ресурсами, к которым обращается исходный сайт. Чаще всего они применяются при отображении рекламных баннеров — так компания, разместившая баннер, может отслеживать поведение пользователя (например, количество переходов). Также этим видом cookie-файлов пользуются аналитические сервисы (например, Google Analytics или «Яндекс Метрика»).

В эту же категорию мы относим куки социальных сетей, устанавливаемые виджетами и кнопками (например, «Поделиться» или «Нравится»). Такие cookie-файлы отвечают за любое взаимодействие с платформами социальных сетей, поэтому могут хранить соответствующие учетные данные и настройки пользователя для ускорения взаимодействия.

Классификация cookie-файлов по значимости

Cookie-файлы также могут быть обязательными и необязательными.

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

В первую очередь необходимость использования обязательных cookie-файлов актуальна для сайтов, имеющих сложную структуру и различные виджеты. К ним относятся, например, сайты электронной коммерции (для работы корзины и проведения оплаты), приложения для фотосъемки (для сохранения полученных изображений на устройство пользователя) и т. д.

Отдельно отметим, что к данным, которые хранятся в обязательных cookie-файлах, относится и упомянутый выше критически важный параметр — Session ID, который отвечает за идентификацию пользователя сайтом. Если пользователь отказывается хранить идентификатор сеанса в куки, сайты размещают его в URL-адресе страницы. Это более опасная практика, поскольку URL не подлежит шифрованию, а также доступен аналитическим и статистическим сервисам и даже пользователям, находящимся с посетителем сайта в одной подсети, что делает его уязвимым для атак типа «межсайтовый скриптинг» (XSS). Именно поэтому при настройке cookie-файлов пользователю зачастую запрещают отключать обязательные куки в целях безопасности.

Пример обязательных cookie-файлов с сайта Osano CMP

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

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

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

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

Особые виды cookie-файлов

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

Суперкуки (supercookie) представляет собой трекинговую технологию, которая позволяет внедрять cookie-файлы в заголовки сайтов и хранить их в нестандартных расположениях (например, локальных хранилищах HTML5, хранилищах плагинов браузера, кэше браузера). Благодаря такому принципу размещения cookie-файлы не будут удалены функцией очистки в настройках браузера. Технология суперкуки используется для персонализации рекламы, а также сбора аналитических сведений о пользователе (например, интернет-провайдерами). С точки зрения приватности технология суперкуки вызывает серьезные сомнения, так как представляет собой постоянный и трудно контролируемый механизм отслеживания пользователя без его согласия и без возможности от него отказаться.

Еще один нестандартный механизм трекинга cookie-файлов — Evercookie (частный случай зомби-куки). Файлы, сохраненные по этой технологии, можно восстановить даже после их удаления при помощи JavaScript. Для восстановления используется уникальный идентификатор пользователя (при наличии), а также следы cookie-файлов во всех возможных хранилищах браузера.

Как регулируется использование cookie-файлов

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

1. General Data Privacy Regulation (GDPR) и ePrivacy Directive (Cookie Law) в Европейском союзе.
   В соответствии с европейским законодательством, обязательные cookie-файлы не требуют согласия пользователя. Это послужило «лазейкой» для владельцев сайтов: периодически за кнопкой «Отклонить все» скрывается запрет только необязательных куки.
2. Lei Geral de Proteção de Dados Pessoais (LGPD) в Бразилии.
   Закон, регулирующий сбор, обработку и хранение данных пользователей на территории Бразилии, во многом вдохновлен принципами GDPR и, аналогично последнему, требует свободного, однозначного и ясного согласия пользователя на использование его персональных данных. При этом LGPD к персональным данным относит более широкий круг информации: например, включает туда также биометрические и генетические данные. Отметим, что соответствие GDPR не означает автоматического соответствия LGPD, и наоборот.
3. California Consumer Privacy Act (CCPA) в штате Калифорния, США.
   Закон о защите конфиденциальности потребителей в Калифорнии относит cookie-файлы к личной информации, сбор и хранение которой должны соответствовать ряду требований. Например, у любого жителя штата есть право запретить перекрестное использование куки, чтобы исключить продажу личных данных. Провайдеры услуг обязаны предоставить пользователям возможность выбора и настройки собираемых данных.
4. Privacy and Electronic Communications Regulations (PECR, EC Directive) в Великобритании — аналог Cookie Law.
   Согласно PECR, публичные информационные веб-сервисы и приложения могут хранить информацию на устройстве пользователя только в двух случаях: если она строго необходима для работы сайта (предоставления услуги) либо если пользователь дал свое согласие на это.
5. Закон № 152-ФЗ «О персональных данных» в Российской Федерации.
   Согласно № 152-ФЗ, под определение персональных данных попадает любая информация, прямо или косвенно относящаяся к физическому лицу. Соответственно, cookie-файлы также могут считаться персональными данными и регулироваться этим законом. Как следствие, на них распространяется требование получить от пользователя явное согласие на обработку данных.

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

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

Помимо законодательных норм использование собственных cookie-файлов также регулируют владельцы сайтов самостоятельно. Аналогичным образом сторонними cookie-файлами управляют владельцы соответствующих сторонних ресурсов (например, Google Analytics). В частности, они принимают решение о том, какая информация и в каком виде попадает в куки. Кроме того, владельцы интернет-ресурсов определяют срок жизни cookie-файлов и их параметры безопасности. Чтобы понять, почему это важно, рассмотрим виды атак на один из самых критически важных типов cookie-файлов — содержащих Session ID.

Методы кражи Session ID

Как мы рассказывали выше, cookie-файлы, содержащие Session ID, являются крайне чувствительными. Именно они представляют наибольший интерес для злоумышленников. В реальных атаках зафиксированы различные способы кражи Session ID, получившие общее название «перехват сеанса» (session hijacking). Далее мы рассмотрим некоторые виды перехвата сеанса.

Session sniffing

Одним из методов кражи cookie-файлов с Session ID является перехват сеанса за счет прослушивания интернет-трафика (session sniffing) между пользователем и сайтом. Эта угроза актуальна для сайтов, которые вместо протокола HTTPS, поддерживающего шифрование трафика, передают данные по открытому HTTP-протоколу. Таким образом куки передаются в открытом виде в заголовках HTTP-запросов, что делает их уязвимыми к перехвату.

Наиболее часто атаки, нацеленные на незашифрованный HTTP-трафик, происходят в общедоступных сетях Wi-Fi, особенно если они не защищены паролем и протоколом безопасности WPA2 или WPA3. Это технология защиты трафика в сетях Wi-Fi с поддержкой AES-шифрования; на текущий момент наиболее безопасной является версия WPA3. Использование защиты WPA2/WPA3 ограничивает возможность перехвата HTTP-трафика, однако только реализация HTTPS-протокола может защитить от session sniffing.

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

Cross-site scripting (XSS)

Межсайтовый скриптинг (cross-site scripting, XSS) эксплуатирует уязвимости в коде посещаемого веб-сайта с целью внедрения на его страницы вредоносного скрипта, часто JavaScript, который срабатывает, когда жертва заходит на сайт. Атака происходит следующим образом: злоумышленник находит уязвимость в исходном коде целевого веб-сайта, позволяющую внедрить вредоносный скрипт. Например, скрипт может принимать вид параметра URL-адреса или комментария на странице. Когда пользователь открывает зараженную страницу, скрипт выполняется в его браузере и получает доступ к данным сайта, включая cookie-файлы с Session ID.

Session fixation

При атаке типа фиксация сеанса (session fixation) атакующий заставляет браузер жертвы использовать заранее определенный идентификатор сеанса (Session ID). Таким образом злоумышленник подготавливает почву для перехвата данных сеанса после того, как жертва перейдет на сайт и выполнит аутентификацию.

Атака происходит следующим образом: злоумышленник заходит на целевой сайт и получает от сервера действительный идентификатор нового сеанса, в рамках которого еще не выполнена аутентификация пользователя. Затем атакующий заставляет браузер жертвы использовать именно этот Session ID, например, отправляя пользователю ссылку, где идентификатор уже указан в URL-адресе (http://example.com/?SESSIONID=ATTACKER_ID). Когда жертва переходит по такой ссылке и входит в свою учетную запись на сайте, веб-сервер связывает подконтрольный злоумышленнику Session ID с аутентифицированным сеансом. После этого злоумышленник может использовать скомпрометированный Session ID для доступа к аккаунту жертвы.

В современных, правильно настроенных веб-приложениях вероятность проведения атаки session fixation значительно ниже, чем атаки вроде XSS. Это объясняется тем, что для большинства современных веб-фреймворков стандартной практикой является смена Session ID после аутентификации пользователя. Тем не менее возможность эксплуатации Session ID описанным способом подчеркивает критическую важность безопасного управления жизненным циклом сеанса, особенно в момент аутентификации пользователя.

Cross-site request forgery (CSRF)

В отличие от атак, нацеленных на прослушивание или фиксацию сеанса пользователя, межсайтовая подделка запроса (cross-site request forgery, CSRF/XSRF) работает на доверии сайта к браузеру пользователя. Злоумышленник заставляет браузер аутентифицированного пользователя без его ведома выполнить нежелательное действие на сайте — например, изменить пароль или удалить данные.

Для проведения подобной атаки злоумышленник создает вредоносную веб-страницу или письмо с вредоносной ссылкой, HTML-кодом или скриптом, который содержит запрос к уязвимому сайту. Когда жертва открывает страницу или письмо, браузер автоматически отправляет прописанный в коде запрос на целевой сайт. В этом запросе содержится вредоносное действие, а также все обязательные cookie-файлы (например, временные), связанные с этим сайтом. На основе полученных действительных куки сайт определяет запрос как легитимный запрос от пользователя и выполняет его.

Частные случаи man-in-the-middle (MitM)

Во время атаки типа «человек посередине» (man-in-the-middle, MitM) злоумышленники не просто прослушивают, но и перенаправляют через свои ресурсы весь трафик жертвы, получая возможность не только читать, но и изменять передаваемую информацию. Атаками такого типа являются, например, подмена DNS или создание фальшивых точек доступа. Таким образом, MitM представляет собой метод перехвата данных, включая cookie-файлы с Session ID, при котором злоумышленник оказывается промежуточным звеном в коммуникации между пользователем и веб-сайтом.

В первую очередь к атакам типа MitM уязвимы сайты, использующие HTTP-протокол. Однако методы man-in-the-middle также представляют опасность для HTTPS-соединений. Злоумышленник может, например, предъявить браузеру пользователя поддельный сертификат SSL/TLS. Браузеры предупреждают о подозрительных или недействительных сертификатах, однако если проигнорировать такое предупреждение, атакующему удастся расшифровать трафик. Также для ослабления защиты трафика злоумышленники могут принудительно использовать HTTP-соединение вместо HTTPS (SSL stripping).

Предсказуемые Session ID

Злоумышленники не всегда крадут Session ID — иногда его можно угадать. В частности, идентификатор вычисляется, если его генерация происходит по предсказуемому шаблону без использования криптографических символов. Например, Session ID может содержать IP-адрес пользователя или последовательные числа. Также для генерации может применяться слабый алгоритм, который использует легко предсказуемые случайные последовательности.

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

Cookie tossing

Этот метод атаки эксплуатирует процесс обработки браузером cookie-файлов, которые установлены поддоменами для одного домена. Если злоумышленник контролирует поддомен, то он может попытаться повлиять на куки — в частности, на Session ID — для домена уровнем выше. Например, если для sub.domain.com установить куки с атрибутом Domain=.domain.com, то этот файл будет действителен и для всего домена.

Таким образом злоумышленник может пробросить вредоносные cookie-файлы с теми же именами, что и cookie-файлы основного домена, например Session_id. Во время отправки запроса на сервер браузер включает в запрос все подходящие cookie-файлы. В результате сервер может ошибочно обработать вредоносный файл с Session ID злоумышленника, и тот получит доступ к сеансу пользователя — это сработает, даже если жертва не посещала страницы на уязвимом поддомене. Кроме того, передача некорректных куки может вызывать ошибки на сервере.

Как защититься и защитить своих пользователей

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

Рекомендации для веб-разработчиков

На уровне сетевого соединения и обмена данными необходимо шифровать весь трафик между клиентом и сервером. Для этого мы настоятельно рекомендуем использовать HTTPS, а также обязательное перенаправление с HTTP на HTTPS. При этом не стоит забывать про заголовок HSTS (HTTP Strict Transport Security), который заставляет браузер всегда использовать HTTPS. Эта мера поможет защититься от атак типов session sniffing, MitM и cookie tossing, так как она затрудняет внедрение злоумышленника в трафик, а иногда делает его практически невозможным.

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

• тщательно проверять (валидировать) и очищать (санитизировать) данные пользовательского ввода;
• внедрить обязательное кодирование данных при выводе на страницу (экранирование) — таким образом браузер не сможет принять вредоносный код за часть страницы и не запустит его;
• использовать флаг HttpOnly для защиты cookie-файлов от доступа из браузера;
• применять стандарт Content Security Policy (CSP) для контроля источников кода — с его помощью можно отслеживать скрипты и другие источники контента, которые разрешается выполнять и загружать на стороне сайта.

Наиболее эффективный метод защиты от атак типа session fixation — это принудительная генерация нового Session ID сервером сразу после успешной аутентификации пользователя. Разработчику сайта необходимо аннулировать старый Session ID (потенциально скомпрометированный) и сгенерировать новый, неизвестный атакующему.

Дополнительной мерой предосторожности является проверка атрибутов cookie-файлов. Для обеспечения защиты необходимо проверить наличие специальных флагов (и установить их в случае отсутствия): Secure и HttpOnly. Secure обеспечивает передачу cookie-файлов по HTTPS-соединению, а HttpOnly предотвращает доступ к ним из браузера, например через скрипты, что помогает защитить чувствительные данные от вредоносного кода. Наличие этих атрибутов предотвратит атаки следующих типов: session sniffing, MitM, cookie tossing и XSS.

Также следует обратить внимание на еще один защищенный атрибут — SameSite, способный ограничить отправку куки. Установите его с параметром Lax или Strict для всех cookie-файлов, чтобы отправлять их только на доверенные веб-адреса при межсайтовых запросах и защититься от атак типа CSRF. Другой распространенный метод предотвращения CSRF-атак — генерация уникальных CSRF-токенов для каждого сеанса пользователя. Такой токен передается браузеру пользователя и включается в каждый HTTP-запрос, выполняющий какое-либо действие на сайте. При получении запроса сайт проверяет наличие и корректность этого токена. Если он отсутствует или не совпадает с ожидаемым, запрос отклоняется как потенциально вредоносный. Это важно, поскольку в случае компрометации Session ID злоумышленник может попытаться подменить CSRF-токен.

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

Самым действенным способом защиты от атаки cookie tossing является использование cookie-файлов с префиксом __Host-. Такие куки могут быть установлены только на том же домене, что и источник запроса, и не могут иметь атрибут Domain. Это гарантирует, что куки, установленные основным доменом, невозможно перезаписать никаким поддоменом.

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

Как мы упоминали выше, при отключении cookie-файлов Session ID может попасть в URL-адрес страницы. Чтобы этого избежать, веб-разработчикам необходимо включать этот идентификатор в обязательные куки, от использования которых нельзя отказаться.

Современные веб-фреймворки часто включают встроенные механизмы, способные предотвратить большинство описанных выше типов атак. Эти защитные компоненты позволяют более безопасно управлять cookie-файлами, упрощая задачу разработчикам. Среди таких механизмов можно выделить регулярную ротацию Session ID после аутентификации, использование флагов Secure и HttpOnly, ограничение срока жизни сеанса, его привязку к IP-адресу клиента, строке User-Agent и другим параметрам, а также генерацию уникальных CSRF-токенов.

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

В зависимости от целей веб-ресурса его владельцы могут пользоваться различными API, например Web Storage API (хранилища localStorage и sessionStorage), IndexedDB и другими альтернативами. При использовании API данные не отправляются при каждом запросе на сервер, что значительно экономит ресурсы и улучшает производительность.

Еще одна интересная альтернатива cookie-файлам — технология server-side, при которой на стороне клиента хранится только Session ID, а остальные данные находятся на сервере. Этот способ является более безопасным, чем хранение информации посредством API, так как данные пользователя не раскрываются на стороне клиента.

Рекомендации для пользователей

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

При посещении веб-сайта необходимо удостовериться, что на нем используется HTTPS. Для этого нужно проверить соответствующий компонент URL-адреса в адресной строке браузера. В некоторых браузерах пользователь может просмотреть дополнительную информацию о безопасности сайта. Так, например, в Google Chrome можно нажать иконку перед адресом сайта и проверить наличие таких параметров, как «Подключение защищено» и «Действительный сертификат». Если эти параметры отсутствуют или данные передаются по HTTP-протоколу, мы рекомендуем проявлять максимальную бдительность при посещении такого веб-сайта и по возможности не вводить на нем никакие личные данные, поскольку он не отвечает базовым принципам безопасности.

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

Мы также рекомендуем периодически очищать данные браузера, в частности куки и кэш, что поможет избавиться от устаревших и потенциально скомпрометированных идентификаторов сеанса.

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

Когда сайт запрашивает согласие на сбор cookie-файлов, наиболее безопасный вариант настройки — отказаться от их использования. Хотя еще раз отметим, что иногда под кнопкой «Отказаться от использования cookie-файлов» скрывается отказ только от необязательных куки. Если этот вариант недоступен, советуем проверить предлагаемые параметры и выбрать только обязательные cookie-файлы. Некоторые сайты предлагают это прямо во всплывающем окне с уведомлением об использовании куки, другие — в дополнительных настройках.

Универсальная рекомендация — не переходить по подозрительным ссылкам — особенно актуальна в контексте предотвращения кражи Session ID. Как мы рассказывали ранее, подобные ссылки могут использоваться для атаки типа session fixation. Тщательно проверяйте URL-адрес: если в нем есть непонятные вам параметры, скопируйте ссылку в адресную строку вручную и удалите их перед загрузкой страницы. Например, длинные последовательности символов в параметрах легитимного URL-адреса могут оказаться идентификатором сеанса злоумышленника. Если же удалить этот параметр, ссылка станет безопасной. Также нелишним будет обратить внимание на корректность самого домена, чтобы случайно не перейти по фишинговой ссылке.

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