CNAME cloaking использует DNS-запись, чтобы трекер выглядел first-party — и обходит блокировку cookie, которая смотрит только на домен в адресной строке.
Все блокировщики third-party cookie опираются на одно допущение: достаточно взглянуть на домен, чтобы отличить third-party от first-party. CNAME cloaking ломает это допущение ещё на уровне DNS — до того, как браузер вообще успевает проверить хоть одну cookie. Владелец сайта указывает для своего поддомена, например metrics.example.com, DNS-CNAME-запись, ведущую на инфраструктуру трекинговой компании, и с этого момента любой запрос к этому поддомену разрешается прямиком до трекера — но для браузера и для любой политики cookie он по-прежнему выглядит точно как сам example.com.
Ключевые выводы
- CNAME-запись позволяет владельцу сайта сделать один из своих поддоменов алиасом на домен стороннего трекера — запросы к этому поддомену обрабатывает трекер, а браузер по-прежнему видит собственное имя хоста сайта.
- Этот приём в самой своей основе обходит блокировку third-party cookie: cookie, установленная «поддоменом», с точки зрения same-site-логики браузера является first-party cookie, потому что видимое имя хоста ни разу не изменилось.
- Опубликованное измерительное исследование обнаружило более 1700 сайтов, маскирующих таким способом свыше 50 разных трекеров — то есть это реально применяемый способ обхода, а не теоретическая конструкция.
- Реакция браузеров расходится: Intelligent Tracking Prevention в Safari ограничивает срок жизни cookie, установленной в обнаруженном CNAME-замаскированном ответе, 7 днями; Brave сам разрешает цепочку CNAME и сверяет реальный адрес назначения со своими фильтр-листами; встроенная Enhanced Tracking Protection в Firefox не разрешает CNAME самостоятельно, поэтому замаскированный трекер способен проскользнуть мимо неё без расширения вроде uBlock Origin.
- Это DNS-родственник bounce tracking: оба приёма эксплуатируют разрыв между тем, «на кого домен похож», и тем, «кто на самом деле его контролирует», только на разных уровнях стека.
Что такое CNAME Cloaking на самом деле
DNS позволяет любому владельцу домена создать CNAME-запись (canonical name), которая говорит: «этот поддомен — просто ещё одно имя для того домена». Это самая обычная, рабочая часть интернет-инфраструктуры — CDN, почтовые провайдеры и SaaS-платформы постоянно используют CNAME, чтобы поддомен клиента указывал на общую инфраструктуру без необходимости держать собственные серверы.
CNAME cloaking использует ровно тот же механизм, но для трекинга. Трекинговый вендор просит своего клиента (владельца сайта) создать поддомен — что-то вроде stats.example.com или t.example.com — и указать в его CNAME-записи собственный домен вендора. С этого момента:
- Ваш браузер запрашивает
stats.example.com. - DNS-разрешение незаметно перенаправляет этот запрос на серверы трекера.
- Ответ — включая любой заголовок
Set-Cookie— приходит от трекера, но с точки зрения адресной строки браузера и его логики same-origin вы всё это время общались сexample.com.
Трекер нигде, где его мог бы увидеть браузер, не выступает как отдельный third-party домен. Он маскируется под поддомен сайта, который вы на самом деле посещаете, и тем самым наследует его first-party доверие.
Цепочка DNS-разрешения за этим приёмом
Механизм работает только благодаря обычному свойству DNS-разрешения: CNAME может указывать на другое имя, которое, в свою очередь, разрешается как обычно, а браузер всё это время имеет дело только с исходным именем хоста, которое он запросил. О том, как в целом устроено это разрешение и почему это само по себе значимая граница приватности, см. наш материал про утечки DNS — CNAME cloaking это другая проблема, но она эксплуатирует тот же самый шаг разрешения.
Вы можете сами проследить эту цепочку для любого имени хоста:
# Проследить полную цепочку CNAME для имени хоста
dig stats.example.com +trace
# Короткий вариант: показать только каноническое имя
dig CNAME stats.example.com +short
Если маркетинговый или аналитический поддомен через CNAME разрешается в домен, который вы не узнаёте — принадлежащий рекламно-технологическому или аналитическому вендору, а не самому сайту, — это и есть паттерн маскировки. Исследователи безопасности документировали это предметно: рецензируемое измерительное исследование обнаружило более 1700 сайтов, использующих CNAME cloaking для направления трафика к более чем 50 разным трекинговым компаниям, что подтверждает: это активно применяемая техника, а не редкий частный случай.
Почему это обходит блокировку third-party cookie
Блокировка third-party cookie работает за счёт сравнения домена в адресной строке браузера с доменом, который пытается установить или прочитать cookie — при несовпадении происходит блокировка. CNAME cloaking никогда не создаёт такого несовпадения. Имя хоста, которое разрешил и к которому подключился ваш браузер, — это, без каких-либо оговорок, поддомен first-party сайта, вне зависимости от того, чьи серверы на самом деле отвечают на запрос. Cookie, установленная в этом ответе, по любому правилу same-site, которое проверяет браузер, является first-party cookie.
Это та же структурная лазейка, что эксплуатирует bounce tracking, только достигнутая иначе: bounce tracking через редирект ненадолго делает first-party собственный домен трекера, а CNAME cloaking заставляет трекера отвечать от имени одного из поддоменов самого сайта. Ни одна из этих техник ни в один момент не нуждается в third-party cookie, поэтому правилу, специально построенному вокруг блокировки third-party cookie, попросту не за что зацепиться.
Реакция браузеров и стандартов
Поскольку обход происходит на уровне DNS, чтобы его исправить, браузеру приходится реально разрешать цепочку и проверять, кто на самом деле отвечает, — а не просто читать переданное ему имя хоста.
Intelligent Tracking Prevention (ITP) в Safari стало первой массовой защитой такого рода. Как объясняет собственный материал WebKit CNAME Cloaking and Bounce Tracking Defense, ITP обнаруживает, когда third-party домен маскируется через CNAME, и ограничивает срок жизни любой cookie, установленной в этом ответе, 7 днями — тем же лимитом, который ITP уже применяет к cookie, созданным через JavaScript, закрывая тем самым лазейку, для обхода которой трекеры и использовали CNAME.
Brave пошёл дальше и сам разрешает цепочку перед тем, как решить, пропускать запрос или нет. В посте Brave Fighting CNAME Trickery описывается сверка двух URL со своими фильтр-листами: исходного запрошенного имени хоста и того же запроса с подставленным вместо него разрешённым каноническим доменом CNAME. Если реальный адрес назначения совпадает с известным трекером, Brave блокирует запрос целиком — ему даже не нужно дожидаться, пока установится cookie.
Enhanced Tracking Protection в Firefox, напротив, не разрешает цепочки CNAME самостоятельно; её блокировка опирается на курируемый список трекинговых доменов, сверяемый с видимым вам именем хоста, — а замаскированный поддомен в этом списке попросту не появляется. На практике пользователи Firefox получают защиту от CNAME-маскировки только через расширение — uBlock Origin умеет сам разрешать цепочку и фильтровать по реальному адресу назначения — а не от встроенной защиты браузера. О том, как работает этот основанный на списке встроенный подход, см. обзор MDN про защиту от отслеживания в Firefox.
Чем CNAME Cloaking отличается от смежных техник
| Техника | Что скрывается | Где происходит трюк |
|---|---|---|
| CNAME cloaking | Настоящий домен трекера | DNS-разрешение first-party поддомена |
| Bounce/redirect-трекинг | Первая-сторонность на собственном домене трекера, на мгновение | Быстрый редирект внутри браузера через трекера |
| Утечка DNS (сбой приватности, не трекинг) | Ваш выбор резолвера, а не личность трекера | Неверная настройка VPN/DNS, раскрывающая запросы вашему ISP |
Последнюю строку стоит проговорить отдельно: утечка DNS — это сбой приватности, раскрывающий ваш собственный браузинг вашему ISP; CNAME cloaking — противоположность этому: сайт намеренно использует DNS, чтобы скрыть от вас личность трекера. Оба явления живут на уровне DNS, но больше между ними ничего общего. Тот же более общий принцип — что ни один технический сигнал сам по себе не рассказывает всю историю, поэтому системы комбинируют несколько сигналов — проявляется и на сетевой стороне: см. как сайты распознают VPN и прокси о том, как тамошним детекторам тоже приходится складывать несколько слабых сигналов, а не доверять одному имени хоста или IP на слово.
Часто задаваемые вопросы
CNAME cloaking незаконен или нарушает политику браузеров?
Ни один закон это не запрещает, и в самом DNS нет понятия «маскировки» — CNAME-записи это обычная инфраструктура. Для браузеров это вопрос политики и обнаружения, а не нарушение протокола: и Safari, и Brave теперь по-разному обращаются с CNAME-замаскированными cookie после их обнаружения, безо всяких изменений в самом стандарте DNS.
Останавливает ли блокировка third-party cookie CNAME cloaking?
Нет. В этом и весь смысл техники — cookie замаскированного трекера по любому правилу, которое проверяет same-site-логика браузера, является first-party cookie, поэтому блокировка third-party cookie в принципе не срабатывает. Чтобы это остановить, нужно разрешить реальную цепочку CNAME и проверить, кто на самом деле контролирует адрес назначения, — именно это и делают Safari и Brave.
Как понять, что посещаемый мной сайт использует CNAME cloaking?
Посмотрите, какие поддомены использует сетевые запросы страницы, затем разрешите их цепочку CNAME командой dig CNAME <имя_хоста> +short. Если поддомен, похожий на маркетинговый или аналитический, разрешается в домен известной рекламно-технологической или аналитической компании, а не самого сайта, — это и есть паттерн. Расширения с собственным DNS-разрешением, вроде uBlock Origin, делают эту проверку автоматически для каждого запроса.
Защищает ли VPN или DNS over HTTPS от CNAME cloaking?
Не напрямую. Шифрование или перенаправление собственных DNS-запросов защищает то, кто видит ваши запросы — см. наш материал про защиту от утечек DNS, — но это никак не меняет то, что владелец сайта настроил для своих собственных поддоменов. CNAME cloaking определяется стороной сайта, а не вашим сетевым путём, поэтому его должен ловить браузер (или расширение), проверяя саму цепочку разрешения, а не защита собственного DNS. И всё же гигиену собственного DNS стоит проверить отдельно: наш тест на утечки VPN и DNS показывает, действительно ли ваш VPN сохраняет приватность ваших DNS-запросов, — то есть ту часть картины, которую вы можете контролировать.
Заключение
CNAME cloaking работает потому, что DNS и политика cookie существуют на двух уровнях, которые изначально не были рассчитаны на взаимную проверку: браузер доверяет разрешённому им самим имени хоста, а правила cookie доверяют представлению браузера о том, что такое «first-party». Пропустив ответ трекера через поддомен-алиас, можно пройти обе проверки, хотя по существу ничего first-party там нет. Safari и Brave закрыли эту лазейку, разрешая реальный адрес назначения перед принятием решения; Firefox по-прежнему полагается на расширения, чтобы делать то же самое. Как и с любой техникой на этом сайте, честный вывод таков: ни одно отдельное правило — блокировка third-party cookie, шифрование собственного DNS или доверие имени хоста на слово — не перекрывает все способы, которыми трекер способен себя замаскировать.
Рекомендуем прочитать:
