Уязвимость в IndexedDB: как через Firefox и Tor Browser можно отследить пользователя
В движке Gecko обнаружена нетипичная уязвимость (CVE-2026-6770), которая позволяет создавать устойчивые идентификаторы пользователей за счёт особенностей работы API IndexedDB. Суть проблемы в том, что сайты могут незаметно "сшивать" сессии, открытые в одном и том же экземпляре браузера, даже если речь идёт о приватном режиме или использовании Tor Browser.
Ошибка затрагивает все браузеры на базе Firefox, включая Tor Browser, и проявляется во всех типах окон. Отслеживание возможно до тех пор, пока не будет полностью перезапущен процесс браузера. После рестарта уникальный идентификатор сбрасывается, но до этого момента сайты способны узнавать, что их открыли в том же самом экземпляре Firefox или Tor, что и ранее.
Проблема уже исправлена в версиях Firefox 150/140.10.0 и Tor Browser 15.0.10. В более ранних сборках у злоумышленников есть возможность использовать IndexedDB не только для локального хранения данных, но и как инструмент кросс-сайтовой идентификации.
Как именно формируется идентификатор
Механизм атаки основан на том, что порядок перечисления баз данных в IndexedDB зависит от внутренних структур браузера, а не от того, как разработчик их создаёт или называет.
Злоумышленнику достаточно на нескольких сайтах выполнить одинаковый сценарий: создать через IndexedDB одну и ту же последовательность баз данных. Затем каждый сайт вызывает метод `indexedDB.databases()` и анализирует порядок, в котором браузер возвращает список созданных БД.
Для разных экземпляров браузера (например, у двух пользователей или у одного пользователя после перезапуска) порядок будет отличаться. Но в пределах одного процесса Firefox или Tor Browser эта последовательность остаётся стабильной, независимо от открываемого домена. Именно она и становится своеобразным "отпечатком" - временным, но достаточно устойчивым для отслеживания.
Пример различий в последовательности
В исследовании приводится показательный пример. В одном и том же сценарии создаётся набор баз данных с именами:
"a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, r"
Однако при вызове `indexedDB.databases()` два разных экземпляра Firefox возвращают их в различных порядках. В одном случае это может быть:
"g, c, p, a, l, f, n, r, d, j, b, o, h, e, m, i, k",
а в другом - уже другой порядок:
"j, b, o, h, e, m, i, k, f, n, r, d, g, c, p, a, l".
Этот порядок остаётся стабильным для конкретного запущенного процесса браузера. Если аналогичный скрипт выполняется на другом сайте, он увидит такое же расположение элементов, что и предыдущий. Это позволяет сопоставить, что оба сайта открыты тем же пользователем в том же экземпляре браузера.
По оценкам, при создании 16 баз данных можно получить около 44 бит энтропии - более чем достаточно, чтобы с высокой точностью различать большое количество уникальных экземпляров браузера.
Почему не помогает приватный режим и очистка данных
Особенно тревожным выглядит тот факт, что на поведение уязвимости не влияют стандартные методы "очищения следов":
- удаление кэша, куки и локальных хранилищ;
- очистка хранилищ сайта средствами самого браузера;
- использование приватного окна;
- в Tor Browser - смена цепочки узлов через кнопку "New Identity".
Все эти действия не меняют внутреннюю раскладку структур, которые определяют порядок перечисления баз данных в IndexedDB. Следовательно, временный идентификатор, выстроенный на основе этого порядка, продолжит работать до тех пор, пока пользователь не завершит процесс браузера и не запустит его заново.
Из-за этого атака особенно опасна для пользователей, которые держат браузер запущенным длительное время, открывая множество сайтов в одном процессе.
В чём корень уязвимости
Проблема связана с внутренним устройством реализации IndexedDB в движке Gecko. Поведение метода `indexedDB.databases()` зависит не от:
- имён баз данных;
- порядка, в котором эти БД были созданы;
- логики работы конкретного сайта.
Вместо этого на порядок влияет размещение во внутренних структурах:
браузер хранит информацию о базах данных в глобальной хэш-таблице, где каждый файл на диске, соответствующий БД, ассоциирован с уникальным UUID-хешем. Именно способ раскладки этих UUID в хэш-таблицу, завязанный на особенности конкретного экземпляра процесса, и определяет итоговый порядок, в котором `indexedDB.databases()` возвращает список БД.
Внешне это выглядит как стабильная, но фактически случайная для каждого процесса перестановка. Для пользователя она незаметна, а для злоумышленника - удобный канал для построения временного идентификатора.
Как атакующий может использовать уязвимость на практике
Сценарий эксплуатации может выглядеть так:
1. Пользователь открывает сайт A.
2. Сайт A через скрипт создаёт фиксированный набор баз данных IndexedDB в определённой последовательности.
3. Сайт A считывает через `indexedDB.databases()` порядок, в котором браузер перечисляет эти БД, и сохраняет получившийся "отпечаток".
4. Позже тот же пользователь открывает сайт B, где внедрён аналогичный код.
5. Сайт B создаёт тот же набор БД и снова считывает порядок.
6. Сравнив полученный порядок с известными значениями, сайт B может понять, совпадает ли он с тем же экземпляром браузера, что и при посещении сайта A.
Таким образом, без использования традиционных трекеров - куки, localStorage или fingerprinting по шрифтам и Canvas - сайты могут синхронизировать свои данные по одному и тому же пользователю, пока он не перезапустит браузер.
Связь обычного и приватного окна
Отдельный риск состоит в том, что этим методом можно сопоставить действия пользователя в обычном и приватном окне.
Если пользователь сначала заходит на сайт в обычном режиме, а затем открывает тот же или другой сайт в приватном режиме, оба окна, как правило, работают в рамках одного процесса или связанной группы процессов. В результате:
- порядок баз данных IndexedDB остаётся одинаковым;
- сайты получают возможность понять, что за приватным окном стоит тот же самый пользователь, что и за обычным.
Это частично сводит на нет ожидания пользователей от приватного просмотра как средства "изолировать" свои действия между сессиями и вкладками.
Что уже сделано для защиты пользователей
Разработчики Firefox и Tor Browser устранили уязвимость, изменив реализацию соответствующего API. В обновлённых версиях поведение `indexedDB.databases()` больше не должно зависеть от внутренних деталей раскладки структур в памяти и специфики конкретного экземпляра процесса.
Фактически, исправление направлено на то, чтобы сделать порядок возвращаемых БД:
- либо детерминированным и одинаковым для всех пользователей;
- либо таким, чтобы он не мог служить источником уникальной энтропии.
Пользователям настоятельно рекомендуется обновить Firefox и Tor Browser до версий, где уязвимость закрыта. В противном случае они потенциально остаются уязвимы к невидимому кросс-сайтовому отслеживанию.
Что могут сделать пользователи до обновления
Если по какой-то причине нет возможности немедленно установить обновления, можно минимизировать риски следующими мерами:
- чаще полностью перезапускать браузер, особенно после посещения чувствительных сайтов;
- по возможности не держать открытыми десятки вкладок сутками в одном и том же процессе;
- разделять активности по разным профилям браузера (хотя это не полная защита, а лишь усложнение атаки);
- в Tor Browser - не полагаться только на кнопку смены идентичности, а периодически полностью закрывать и заново запускать приложение.
Однако все эти меры являются лишь временными обходными путями. Полноценная защита достигается только установкой версии с закрытой уязвимостью.
Значение уязвимости для приватности
Этот дефект наглядно демонстрирует, что даже относительно "невинные" веб-API, вроде IndexedDB, могут неожиданно превращаться в инструмент слежки. Проблема не в самом факте существования локальной базы данных, а в мелких деталях реализации - от порядка перечисления элементов до организации внутренних хэш-таблиц.
Для разработчиков браузеров это сигнал о необходимости оценивать любые подобные особенности с точки зрения приватности. Даже если деталь кажется сугубо технической и внутренней, злоумышленники могут превратить её в канал побочной утечки данных (side-channel).
Выводы
Уязвимость в реализации IndexedDB в движке Gecko сделала возможным формирование устойчивых временных идентификаторов, связывающих разные сайты в пределах одного процесса браузера. Она затрагивала Firefox и все основанные на нём браузеры, включая Tor Browser, и работала даже в приватном режиме, не реагируя на очистку локальных данных и смену Tor-цепочки.
Ключевая причина - зависимость порядка, возвращаемого методом `indexedDB.databases()`, от внутренних структур и размещения UUID-хешей в глобальной хэш-таблице. Это превращало последовательность баз данных в уникальный "отпечаток" экземпляра браузера.
Проблема уже устранена в новых версиях Firefox и Tor Browser, а пользователям следует как можно скорее установить обновления. Этот инцидент ещё раз подчёркивает: защита приватности в сети требует не только отключения трекеров и блокировки рекламы, но и внимательного отношения к тонкостям реализации даже базовых веб-технологий.
