Браузеры на базе WebKit для iOS и macOS можно настроить таким образом, чтобы весь веб‑трафик проходил через прокси‑серверы. Однако исследователи обнаружили три функции WebKit — предварительную выборку DNS, запросы WebAuthn Related Origin Requests и WebTransport — которые обходят настроенный прокси и отправляют трафик напрямую с устройства, что раскрывает реальную сеть пользователя.
Та же проблема затрагивает и iCloud Private Relay от Apple.
Три функции WebKit обходят конфигурацию прокси и отправляют трафик напрямую с устройства:
-
предварительная загрузка DNS разрешает имена хостов через обычный DNS‑путь устройства, что раскрывает реальные DNS‑серверы пользователя, а не прокси. Доступна с iOS 26.0;
-
запросы WebAuthn Related Origin Requests заставляют службу учётных данных операционной системы загружать файл проверки непосредственно с устройства. Это раскрывает реальный IP‑адрес устройства. Работает с iOS 18.0;
-
WebTransport открывает прямое HTTP/3-соединение и обходит прокси, что также раскрывает реальный IP‑адрес устройства. Доступна с iOS 26.4.
При этом VPN не затрагиваются, поскольку они туннелируют весь сетевой трафик устройства на системном уровне.
Чтобы проверить утечки, можно посетить сайт с демонстрацией.
Отмечается, что представленная в iOS 17 и macOS 14, функция WKWebsiteDataStore.proxyConfigurations позволяет браузерам на основе WebKit направлять весь свой веб‑трафик через прокси‑серверы на уровне приложения. Этот API является основой прокси‑браузеров на iOS: каждое сетевое соединение, устанавливаемое веб‑страницей, должно проходить через настроенный прокси‑сервер, поэтому веб‑сайты видят только IP‑адрес прокси.
Расследование проблемы началось с сообщения об ошибке от пользователя приватного браузера Psylo, который заметил утечки DNS при посещении только определённых веб‑сайтов. При этом Psylo направляет весь трафик от каждого хранилища через частную прокси‑сеть Mysk (или собственный настроенный пользователем прокси‑сервер), поэтому все DNS‑запросы должны исходить от прокси‑сервера, а не от устройства.
Компания обнаружила источник утечек DNS, а также ещё две функции, которые фактически раскрывают реальный IP‑адрес устройства. Все три находятся в WebKit, где они обходят настройки прокси, предоставляемые WKWebsiteDataStore.proxyConfigurations. Поскольку политика App Store от Apple требует, чтобы каждый браузер iOS использовал WebKit, проблема затрагивает все браузеры iOS, которые полагаются на этот API для проксирования, включая iOS Tor и Psylo. Эти утечки также присутствуют в iCloud Private Relay от Apple.
iCloud Private Relay — это функция конфиденциальности от Apple для подписчиков iCloud+. При включении она проксирует веб‑трафик и DNS‑запросы Safari через двухступенчатую систему ретрансляции, разработанную таким образом, чтобы ни одна сторона, даже Apple, не могла видеть, кто и какие сайты посещает. Как оказалось, все три утечки, описанные в этой статье, происходят вне стандартного процесса загрузки страниц WebKit, а это значит, что Private Relay тоже подвержен им.
Предварительная загрузка DNS позволяет веб‑сайту запрашивать у браузера разрешение имени хоста до того, как оно потребуется. Таким образом, когда позже потребуется подключиться к этому имени хоста, поиск уже будет выполнен, и соединение начнётся быстрее. Это делается с помощью HTML‑тега .
Когда страница включает этот тег, WebKit разрешает имя хоста через обычный DNS‑путь устройства, независимо от любого прокси, установленного браузером через WKWebsiteDataStore.proxyConfigurations. Страница может встраивать уникальные имена хостов для каждого посетителя в эти теги, а затем наблюдать, как запросы поступают на собственный авторитетный DNS‑сервер из реальной сети посетителя, а не из сети прокси.
Private Relay не перехватывает этот запрос. Обычно он проксирует DNS‑запросы Safari, но эти предварительные запросы пропускают его. Они достигают авторитетного сервера из реальной сети устройства, даже если Private Relay включён.
Настольный Safari поддерживает с Safari 5, но iOS игнорировала его до iOS 26.0, когда WebKit включил его в том же обновлении, которое удалило старую, неявную спекулятивную предварительную загрузку DNS в iOS (ошибка 285744, 290327@main; данные browser‑compat). Этот резолвер был переписан годом ранее, чтобы исключить имена хостов из системных журналов во время приватного просмотра (ошибка 272190, 279199@main).
WebAuthn — это веб‑стандарт, лежащий в основе паролей. Обычно пароль привязан к одному домену, но запросы к связанным источникам (Related Origin Requests) позволяют организации использовать одну комбинацию для небольшого набора принадлежащих ей доменов.
Когда страница запрашивает учётные данные, rpId которых отличается от rpId её собственного источника, а клиент сначала получает JSON‑файл https:///.well‑known/webauthn, в котором перечислены источники, использующие этот rpId.
Эта проверка подлинности не выполняется сетевым стеком браузера. WebKit передаёт запросы WebAuthn службе учётных данных операционной системы, которая сама отправляет HTTPS‑запрос непосредственно с устройства, не зная о каком‑либо прокси‑сервере, настроенном хост‑приложением. Страница может установить rpId на хост по своему выбору, и запрос выполняется даже без взаимодействия с пользователем.
Та же логика применима и к iCloud Private Relay. Поскольку запрос на получение данных инициируется службой учётных данных операционной системы, а не Safari, он никогда не проходит через проксированный путь Private Relay. В любом случае, целевой сервер видит реальный IP‑адрес устройства.
Apple анонсировала эту функцию для iOS 18.0 / Safari 18.0 в разделе «Функции WebKit в Safari 18.0». Часть инфраструктуры WebKit появилась ранее в том же году (ошибка 268426, 274592@main) и даже была включена, в неактивном виде, в iOS 17.4.
WebTransport — это альтернатива WebSocket с низкой задержкой. Он работает поверх HTTP/3 и QUIC, предлагает несколько независимых потоков, а также ненадёжную доставку дейтаграмм и может переключаться на HTTP/2 там, где QUIC недоступен.
Вызов функции new WebTransport(url) открывает QUIC‑соединение напрямую с устройства. WebKit устанавливает соединение со своими собственными сетевыми параметрами и никогда не предоставляет ему прокси‑сервер сессии, поэтому сервер видит реальный IP‑адрес устройства, а не прокси.
Private Relay здесь тоже не помогает. WebKit устанавливает соединение вне веб‑трафика, который обрабатывается Private Relay, поэтому сервер WebTransport узнает реальный IP‑адрес устройства, даже если Private Relay включён.
Есть одно исключение: уровень безопасности Onion Browser “Silver” настраивает WebKit в режиме блокировки (Lockdown Mode), который полностью отключает WebTransport, поэтому пользователи Onion Browser с уровнем Silver не затронуты утечкой.
Первые упоминания об API появились в 2023 году (ошибка 260810, 267408@main), но они оставались отключёнными до декабря 2025 года.
В Psylo 1.3.1 устранили все три утечки. Теперь браузер блокирует подсказки dns‑prefetch, WebTransport отключили по умолчанию, а функции Passkeys и WebTransport имеют законное применение, поэтому обе можно повторно включить в любое время с помощью переключателей для каждого отдельного модуля.
В 2025 году Apple выпустила экстренные обновления безопасности для WebKit, чтобы исправить ошибку нулевого дня. Компания описала её как эксплуатируемую в «чрезвычайно сложных» атаках. Тогда Apple пояснила, что злоумышленники могут эксплуатировать уязвимость, используя вредоносный веб‑контент, чтобы выйти из песочницы. Проблему записи за пределами допустимого диапазона исправили с помощью улучшенных проверок для предотвращения несанкционированных действий.
Источник: habr.com