Утечка данных через браузерные расширения: методы аудита разрешений

Такая поверхность уязвимости часто остаётся вне стандартного контроля: по данным отчёта LayerX за 2025 год, хотя бы одно расширение установлено в рабочем браузере у 99% сотрудников.

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

Как расширение получает доступ к данным

Архитектура браузерного расширения обычно включает фоновые и контентные скрипты. Фоновая часть выполняет задачи в браузере. Контентный скрипт работает в контексте страницы и взаимодействует с её DOM — структурой, в которой находятся текст, поля ввода и другие элементы интерфейса.

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

Ключевой параметр — область сайтов, на которых расширению разрешено работать. В манифесте расширения это могут обозначать шаблоны <all_urls> или *://*/*. Они соответствуют широкому охвату: доступ распространяется практически на любые сайты. Когда такой охват сочетается с API для работы с cookies, сетевыми запросами или внедрением скриптов, риск заметно возрастает.

Особое внимание требуется сессионным данным. Разрешение cookies в сочетании с доступом к сайтам может открыть расширению чтение cookies, в том числе помеченных флагом HttpOnly. Этот флаг ограничивает доступ из обычного JavaScript страницы, но не следует считать его универсальной защитой от расширений с соответствующими полномочиями.

Опасность определяется совокупностью прав и фактическим поведением:

• доступ к широкому набору сайтов задаёт масштаб возможного сбора;
• API cookies открывает путь к чтению cookie-файлов;
• webRequest связан с обработкой сетевых запросов;
• scripting позволяет внедрять скрипты в страницы;
• контентные скрипты могут обращаться к DOM тех страниц, где им разрешено выполняться.

Отдельное разрешение не доказывает злонамеренность. Блокировщику рекламы, переводчику или инструменту разработчика может требоваться доступ к страницам для выполнения основной функции. Аудит фиксирует несоответствие между заявленным назначением, реальным охватом и запрошенными правами. Именно такое несоответствие требует расследования.

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

Что меняет Manifest V3

В экосистеме Chromium действует модель расширений Manifest V3. В ней права доступа к внешним URL выносятся в отдельные поля host_permissions и optional_host_permissions. Это позволяет отделить доступ к сайтам от других разрешений и в некоторых сценариях запрашивать его по мере необходимости.

В Manifest V3 синхронное блокирующее изменение сетевых запросов через webRequestBlocking заменено декларативным механизмом declarativeNetRequest. Для корпоративных политик предусмотрены исключения. Это ограничивает один из способов перехвата и изменения трафика, но не устраняет доступ расширений к данным полностью.

Контентные скрипты по-прежнему могут работать с DOM страниц, если расширению разрешён доступ к соответствующему сайту. Права в host_permissions также сохраняют значение: широкий список хостов увеличивает количество страниц, на которых расширение способно выполнять свои функции. Следовательно, переход на Manifest V3 не даёт оснований закрывать аудит.

При проверке манифеста нужно смотреть на несколько групп параметров:

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

Для корпоративного аудита следует отдельно учитывать рабочие веб-приложения: почту, системы управления документами, CRM, панели администрирования и сервисы с активной авторизацией. Если расширение имеет доступ ко всем сайтам, оно может пересекаться с каждой из этих категорий. Это увеличивает потенциальный ущерб при компрометации аддона.

Автообновление и цепочка поставок

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

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

Случай ModHeader показывает масштаб потенциальной экспозиции: до обнаружения скрытого сборщика данных утилита имела 1,6 млн установок. Само число установок не доказывает безопасность или опасность продукта. Оно показывает, что популярность не заменяет технический аудит и контроль обновлений.

Для оценки цепочки поставок фиксируют:

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

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

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

Ручной аудит установленных расширений

Экспресс-аудит списка расширений вручную занимает ориентировочно 10 минут. Этого хватает для первичной сортировки, но не для полноценной экспертизы кода или сетевого поведения. Результат первичной проверки — перечень аддонов, которые нужно оставить, ограничить, удалить или изучить отдельно.

1. Составьте инвентаризацию. Зафиксируйте название, версию, издателя, источник установки и пользователя. В корпоративной среде соберите данные по всем управляемым профилям. Не считайте список в одном браузере полным реестром организации.

2. Сопоставьте назначение и наличие. Для каждого аддона укажите, какую рабочую задачу он решает и кто является владельцем этой потребности. Расширения без установленного пользователя или понятного сценария использования требуют отдельного решения.

3. Проверьте области доступа. Найдите в манифесте host_permissions, optional_host_permissions и шаблоны сайтов. <all_urls> и *://*/* означают широкий охват. Для инструмента, которому нужен один внутренний сервис, такой доступ следует считать аномалией до объяснения.

4. Разберите комбинации API. Отдельно отметьте cookies, webRequest и scripting. Их сочетание с широким доступом к сайтам формирует повышенный риск. Уточните, какие функции продукта действительно требуют каждой возможности.

5. Проверьте обновления и издателя. Сравните текущую версию с ранее утверждённой. Зафиксируйте неожиданные изменения функций, владельца или набора разрешений. Автоматическое обновление делает периодический пересмотр обязательным.

6. Ограничьте доступ. Если браузер позволяет выдать разрешение только на конкретных сайтах или только при активации, используйте минимальную область, достаточную для работы. Не выдавайте доступ ко всем сайтам по инерции.

7. Примите решение и сохраните основание. Неиспользуемый аддон удаляют. Расширение с широкими правами направляют на дополнительную проверку или заменяют. Для разрешённого исключения фиксируют деловую необходимость, владельца и срок пересмотра.

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

Результат аудита полезно оформлять как реестр риска. Для каждого расширения фиксируются запрошенные разрешения, затрагиваемые сайты, обоснование установки, версия и принятое решение. Такая запись позволяет сравнивать состояние при следующей проверке и быстро находить отклонения после обновления.

Контроль в корпоративной среде

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

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

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

При признаках утечки порядок действий должен быть техническим:

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

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

Итоговый чек-лист митигации

• Удалить расширения без подтверждённого рабочего назначения.
• Ограничить доступ к сайтам конкретными доменами, когда это возможно.
• Проверять комбинации <all_urls> или *://*/* с cookies, webRequest и scripting.
• Повторно оценивать аддоны после обновлений и смены издателя.
• Запретить неконтролируемую установку в управляемых корпоративных профилях.
• Разделять профили для обычной работы и доступа к чувствительным системам.
• При подозрении на компрометацию отозвать доступ расширения и проверить активные сессии.

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