Что такое суперкуки (supercookies) и как от них избавиться

О чём эта статья

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

Что такое обычная cookie

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

• сохранение состояния входа (чтобы не вводить пароль при каждом визите);
• корзина покупок;
• персонализация интерфейса.

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

• удалить куки через настройки браузера;
• запретить сторонние куки;
• настроить автоматическое удаление при закрытии браузера.

ALT: Иллюстрация взаимодействия браузера и сайта через обычную cookie, показывающая сохранение состояния (корзина/вход).

Что такое суперкуки и в чём их особенность

Определение в одной строке: суперкуки — это механизмы отслеживания, которые не полагаются только на браузерное хранилище, а используют дополнительные каналы (HTTP‑заголовки, наружнее хранилище, метаданные соединения) и поэтому устойчивы к стандартным методам очистки.

Ключевые отличия от обычных cookie:

• не хранятся исключительно в браузере;
• могут добавляться провайдером в HTTP‑запросы (например, заголовки типа X‑UIDH);
• способны связывать активность в приложениях и в браузере;
• иногда позволяют «восстановить» удалённые куки — так называемое «bootstrap» связывание идентификаторов.

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

Конкретный пример: Verizon и UIDH

В 2016 году Федеральная комиссия по связи США (FCC) наложила штраф на Verizon за использование уникального идентификатора (UIDH), часто называемого «supercookie». Этот заголовок позволял рекламодателям связывать посещения разных сайтов и получать профиль поведения пользователя.

Verizon предлагал опцию отказа, но отказ не обязательно отключал сам заголовок — он лишь ограничивал передачу сопутствующей демографической информации партнёрам и не всегда работал при участии в дополнительных программах (например, Selects).

Важно: точные технические детали реализации зависят от провайдера. Некоторые используют заголовки типа X‑UIDH, другие — свои наименования.

Опасности суперкуки

Основные риски:

• приватность: любой сайт, получив заголовок/идентификатор, может связать визиты и собрать профиль;
• восстановление истории: суперкод может служить «якорем», позволяющим рекламникам воссоздать старые куки и продолжить слежение;
• утечка при компрометации: если база соответствий между идентификатором и пользователем попадёт в чужие руки, это станет серьёзной утечкой персональных данных;
• обход пользовательских настроек: некоторые реализации игнорировали «Limit ad tracking» в мобильных ОС.

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

Что отправляет суперкуки — типы данных

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

Примеры содержимого (обобщённо, без конкретных значений):

• псевдоидентификатор: длинная случайная или хешированная строка;
• временная метка или версия идентификатора;
• опционально: признаки сегментации (демография, интересы) — если провайдер продаёт данные партнёрам.

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

Что такое zombie cookie

Zombie cookie — вариант суперкуки, который «воскресает» после удаления. Механика:

• трекер хранит копии идентификатора в нескольких местах (localStorage, canvas RGB, ETag, Flash/Silverlight — если поддерживается);
• когда пользователь удаляет куки, скрипт проверяет альтернативные хранилища и восстанавливает куки;
• если хотя бы одно резервное хранилище осталось, вся структура может быть восстановлена.

Почему это работает: веб‑приложения могут использовать разные браузерные и внеброузерные механизмы хранения; удаление только cookie не затрагивает их все.

Когда суперкуки не сработают (контрпример)

Суперкейки менее эффективны в следующих ситуациях:

• весь трафик проходит через шифрованный туннель (VPN) или TOR, где провайдер не видит и не модифицирует содержимое;
• все соединения целиком защищены HTTPS и нет промежуточных точек, где заголовки можно модифицировать (в типичной реализации HTTPS предотвращает модификацию заголовков на пути);
• провайдер не реализует или не вставляет идентификаторы на своей сети;
• корпоративные прокси/фильтры могут удалять неизвестные заголовки по политике.

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

Как обнаружить наличие суперкуки — мини‑методология (5 шагов)

1. Подготовка: отключите VPN и мобильные прокси, используйте мобильную сеть оператора (если тестируете мобильного провайдера) или домашний интернет (если тестируете ISP).
2. Отправьте простой HTTP‑запрос на сервис, который возвращает ваши входящие заголовки, — например http://httpbin.org/headers или любой echo‑endpoint.
3. Просмотрите ответ сервера и ищите нестандартные заголовки (X‑UIDH, X‑VZN‑UID, X‑Unique‑Id и т. п.).
4. Повторите тест через HTTPS — для сравнения. Если заголовок появляется только на HTTP, провайдер вставляет его в незашифрованный трафик.
5. Повторите тест с VPN/TOR. Если заголовок исчезает при VPN, это подтверждает внедрение на уровне провайдера.

Пример команды curl для проверки (пример для HTTP):

curl -i -s http://httpbin.org/headers

Или более читабельно:

curl -s http://httpbin.org/anything | jq .headers

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

ВНИМАНИЕ: многие современные сайты уже используют HTTPS по умолчанию; для теста используйте именно HTTP‑эндпоинты, иначе вы не увидите вмешательство в незашифрованные заголовки.

Как удалить или нейтрализовать суперкуки — практические шаги

Короткий ответ: полностью удалить не всегда возможно, но можно эффективно нейтрализовать риск.

Шаги для обычного пользователя:

1. Включите всегда HTTPS: устанавливайте расширение типа HTTPS Everywhere или используйте браузер, который принудительно поднимает соединение до HTTPS.
2. Используйте надёжный VPN: VPN туннелирует весь трафик до внешнего провайдера VPN, поэтому локальный ISP не сможет вставлять заголовки.
3. Используйте Tor для высокой анонимности: Tor предотвращает отслеживание провайдером, но снижает скорость и может нарушать некоторые сайты.
4. На мобильных устройствах проверьте настройки оператора: провайдеры иногда предлагают страницу отказа. Пример: Verizon — https://www.vzw.com/myprivacy (войдите в аккаунт и найдите Relevant Mobile Advertising). Помните: отказ может не отключать сам заголовок, а лишь ограничивать передачу демографических данных партнёрам.
5. Смените оператора/провайдера, если он системно внедряет идентификаторы и не предлагает реального отключения.
6. Используйте расширения/скрипт‑блокеры и блокировку трекеров (не все решения помогают против ISP‑вставки, но уменьшают дополнительные риски).

Шаги для IT‑специалистов и организаций:

• Проконтролируйте трафик с помощью доверенного промежуточного прокси (TLS‑терминация внутри организации) и мониторинга заголовков.
• Включите политику HSTS и по возможности принудительное использование HTTPS на серверах.
• Рекомендуйте сотрудникам использовать корпоративный VPN для удалённой работы.
• Аудитируйте трафик через echo‑сервисы и автоматизируйте проверку наличия нестандартных заголовков.

Пример подхода для проверки в скрипте (bash):

#!/bin/bash
# Проверка наличия нестандартных заголовков
curl -s http://httpbin.org/anything | jq -r '.headers | to_entries[] | "\(.key): \(.value)"' | grep -i "x-uid\|x-vzn\|x-unique"

Если команда возвращает строку — есть повод копать дальше.

Playbook: что делать, если вы обнаружили суперкуки

1. Зафиксируйте доказательства: снимки ответов echo‑сервисов, время теста, конфигурация сети.
2. Повторите тест с VPN/Tor/мобильной сетью для сравнения.
3. Свяжитесь с поддержкой провайдера и потребуйте разъяснений и опции полного отключения. Запрашивайте документальный ответ.
4. Если провайдер не отвечает или отказывает, рассмотрите смену провайдера.
5. Если вы в организации, сообщите в отдел безопасности и выполните аудит доступа к журналам.
6. При признаках утечки персональных данных — уведомите юридический отдел и, при необходимости, регулятора.

Дерево решений (Mermaid)

flowchart TD
  A[Подозрение на трекинг] --> B[Выполнить тест на httpbin.org]
  B --> C{Найден идентификатор в заголовках?}
  C -- Да --> D[Повторить с VPN/TOR]
  C -- Нет --> E[Вероятно нет внедрения]
  D --> F{Исчез при VPN?}
  F -- Да --> G[Использовать постоянный VPN / сменить провайдера]
  F -- Нет --> H[Возможны серверные/прикладные трекеры — дальше анализ]
  G --> I[Отслеживание нейтрализовано]
  H --> I
  E --> I

Роль‑ориентированные чек‑листы

Для конечного пользователя:

• Проверил через http://httpbin.org/headers на предмет нестандартных заголовков;
• Включил HTTPS по умолчанию;
• Подключился к надёжному VPN и повторил тест;
• Проверил настройки приватности в аккаунте провайдера.

Для администратора безопасности:

• Выполнил регулярный аудит входящих заголовков с контрольных географических точек;
• Настроил оповещения при появлении неизвестных заголовков;
• Обновил рекомендации BYOD и политики удалённого доступа;
• Обеспечил централизованный VPN для удалённых сотрудников.

Для инсайдера продукта/маркетолога:

• Оценил законность использования сетевых идентификаторов в вашей юрисдикции;
• Определил риски репутации при использовании таких данных;
• Рассмотрел альтернативные методы сегментации, не нарушающие приватность.

Юридические и приватность‑заметки (GDPR и локальное регулирование)

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

• Запросите у провайдера информацию: какие данные он собирает и кому передаёт;
• Если вы в ЕС, используйте запросы субъекта данных (DSR) при необходимости;
• Включите в оценку воздействия на защиту данных (DPIA) любые процессы, включающие сетевые идентификаторы.

Это не юридическая консультация — при сомнениях обратитесь к профильному юристу.

Безопасность и технические меры жёсткого уровня

• Принудительный TLS: настроить HSTS, TLS 1.2+ и предпочтительные шифры;
• DNS‑безопасность: использовать DoT/DoH (DNS over TLS / DNS over HTTPS), чтобы скрыть DNS‑запросы от провайдера;
• Централизованный VPN для организаций с логированием и мониторингом;
• Минимизация передачи чувствительных идентификаторов в приложениях (не включать номера телефонов в явном виде в запросы).

Совместимость и миграция: на что обратить внимание

• Некоторые сайты и API всё ещё используют HTTP. При переходе на HTTPS проверьте, не ломается ли функциональность в приложениях;
• VPN и Tor могут влиять на производительность и блокироваться некоторыми сервисами;
• При смене провайдера протестируйте поведение трафика по вышеописанным методам.

Критерии приёмки

• Нет нестандартных идентификаторов в заголовках при тесте по HTTP на контрольной точке (при условии, что вы используете незашифрованный канал для теста);
• При использовании корпоративного VPN ненаблюдается вставка дополнительных заголовков провайдером;
• Документирован ответ провайдера с подтверждением отключения отслеживания или планом действий.

Примеры тестов и приемочных сценариев

Тест 1 — Проверка домашнего подключения:

1. Отключить VPN.
2. Выполнить curl http://httpbin.org/headers.
3. Зафиксировать результат.
4. Включить VPN и повторить. Ожидаемый результат: нестандартных заголовков нет при VPN.

Тест 2 — Мобильная сеть оператора:

1. Подключиться по мобильной сети оператора без VPN.
2. Выполнить тест на echo‑endpoint.
3. Если найден заголовок, сделать снимок экрана и обратиться в поддержку оператора.

Когда ничего не помогает: рекомендации по минимизации ущерба

• Используйте отдельный профиль/устройство для приватного серфинга по VPN или Tor;
• Минимизируйте передачу идентифицирующей информации в теле запросов;
• Регулярно меняйте контактные данные и пароли в сервисах, где это возможно;
• Оценивайте альтернативы: провайдеры, уважающие приватность.

Итог и дальнейшие шаги

Суперкейки — это серьёзная угроза приватности, потому что они работают вне контроля обычных инструментов браузера. Полного и универсального «удалителя» нет: лучший набор мер — комбинация технической защиты (HTTPS, VPN, DoH/DoT), мониторинга и давления на провайдера (запросы, жалобы регулятору, смена поставщика). Для организаций добавляются централизованные решения и аудит.

Important: если вы выявили суперкод в сети вашей организации, повод инициировать инцидент‑response и уведомить руководство по безопасности.

Краткий план действий для обычного пользователя: проверьте через echo‑сервис, включите VPN/HTTPS, обратитесь к провайдеру, при необходимости смените провайдера.

Короткая глоссарий (1 строка на термин)

• Cookie — браузерный фрагмент данных для хранения состояния;
• Supercookie — устойчивый идентификатор, используемый вне стандартного cookie‑хранилища;
• Zombie cookie — резервная копия идентификатора, способная восстановить удалённый cookie;
• UIDH — пример заголовка, используемого провайдерами для идентификации пользователей.

Ресурсы и ссылки

• Пример для проверки заголовков: http://httpbin.org/headers
• Verizon privacy page: https://www.vzw.com/myprivacy
• EFF — материалы по идентификаторам и приватности (поиск на eff.org)

Конец статьи.