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

Мы верим, что уязвимости, подобные этой, должны открыто обсуждаться, чтобы помочь браузерам как можно быстрее устранить их, поэтому отправили баг-репорт мейнтейнерам WebKit, создали демонстрацию уязвимости и открыли репозиторий с её кодом.

Ниже обсудим баг, который появился в реализации API IndexedDB в Safari и позволяет любому веб-сайту отслеживать активность в интернете и даже раскрыть вашу личность. Упомянутую демонстрацию вы найдёте здесь.

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

Базы данных IndexedDB связываются с конкретным источником. При этом ассоциированные с различными источниками документы или скрипты не могут взаимодействовать с базой данных, которая связана с другими источниками. Если вы хотите больше узнать о работе API IndexedDB, обратитесь к документации MDN или к спецификации W3C.

Утечка IndexedDB в Safari 15

В Safari 15 на macOS, во всех браузерах iOS и iPadOS 15 API IndexedDB нарушает правило ограничения домена. Всякий раз, когда сайт взаимодействует с какой-то базой данных, в рамках одной сессии во всех активных вкладках, фреймах и окнах создаётся пустая копия базы данных с тем же именем.

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

Чем опасна утечка?

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

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

Так происходит на YouTube, Google Calendar и Google Keep. Все эти сайты создают базы данных, которые в названии содержат идентификатор аутентифицированного пользователя Google. Если пользователь вошёл в несколько аккаунтов, такие базы данных создаются для всех аккаунтов.

Идентификатор Google генерируется самим Google и принадлежит единственному аккаунту. Он может использоваться API Google, чтобы получить открытую информацию о владельце аккаунта, а предоставленная этими API информация используется многими сервисами. В общем случае как минимум доступна фотография профиля пользователя. Чтобы узнать больше, обратитесь к документации Google People API.

Всё это означает, что вредоносные сайты могут узнать личность пользователя, также это позволяет связать воедино несколько отдельных учётных записей конкретного человека. 

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

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

Как много сайтов затронуто?

Чтобы понять, как много сайтов используют IndexedDB, мы проверили домашнюю страницу Alexa Top 1000. Результаты показали, что более 30 сайтов работают с уязвимой базой прямо на домашней странице, где не нужно аутентификации или других действий пользователя.

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

Иногда базы данных содержали UUID, созданные внутренними ресурсами, а именно рекламными сетями. Интересно, что загрузка таких ресурсов блокируется функцией предотвращения слежения в Safari. Эта блокировка эффективно предотвращает утечку имён баз данных. Также утечек не происходит, когда ресурсы заблокированы другими способами, например AdBlock или полным блокированием выполнения JavaScript.

Защищает ли приватный режим Safari от уязвимости?

Правило ограничения домена защищает, если следовать ему. Это надёжный механизм для окон во всех режимах. Сайты одного источника не должны иметь доступ к ресурсам другого происхождения, независимо от того, использует ли пользователь приватный режим, если это явно не разрешено через CORS.

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

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

Обратите внимание: в других браузерах на базе WebKit, например в Brave или Google Chrome на iOS, приватные вкладки, как и неприватные, используют одну и ту же сессию браузера.

28 ноября 2021 года мы сообщили об утечке в баг-трекер WebKit. Баг зарегистрирован под номером 233548.

Демонстрация

Простая страница демонстрирует, как веб-сайт может идентифицировать аккаунт посетителя. Она доступна по этой ссылке.

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

Демо представляет более 20 сайтов в других вкладках или окнах, включая Google Calendar, YouTube, Twitter и Bloomberg. Утечка на этих сайтах возможна потому, что имена баз данных на них достаточно специфичны, чтобы точно определить личность пользователя. Уязвимые браузеры — это Safari 15 на Mac OS и практически все браузеры на iOS и iPadOS. Apple Store требует, чтобы все они использовали WebKit. Попробуйте демо.

Как воспроизвести утечку?

Чтобы воспроизвести утечку самостоятельно, вызовите функцию IndexedDB.databases(). Когда сайт откроет другие фреймы, вкладки или окна для взаимодействия с другими базами, вы увидите их пустые дубликаты из других источников.

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

При каждом обновлении страницы базы дублируются снова, и, похоже, они независимы от исходных баз данных. Удалить их невозможно даже функцией IndexedDB.deleteDatabases().

Как защитить себя?

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

Более того, уязвимости межсайтового скриптинга могут эксплуатироваться целенаправленно и через доверенные сайты, хотя здесь риск гораздо меньше. Альтернатива для пользователей Safari и Mac — временное переключение на другой браузер.

К сожалению, на мобильных операционных системах (iOS и iPadOS) переключиться невозможно: в них уязвимы все браузеры. Единственная защита — это обновить браузер или OS, когда проблему решит Apple. Мы надеемся, что эта статья поможет другим людям узнать о проблеме.

А на наших курсах вы сможете погрузиться в веб-технологии и кибербезопасность, чтобы научиться решать проблемы бизнеса:

• Профессия Этичный хакер

• Профессия Fullstack-разработчик на Python

Узнайте подробности здесь.