В конце 2024 года supply chain-атака на корпоративное расширение Cyberhaven для Chrome показала одну неприятную вещь: один скомпрометированный аккаунт разработчика превращает доверенный плагин в инструмент эксфильтрации. По данным исследования IIT Jammu (2025, arxiv), атакующие использовали social engineering и OAuth token abuse для публикации вредоносного обновления - механизмы проверки Chrome Web Store это проглотили. «Лаборатория Касперского» считает, что с 2020 по середину 2022 года более 4,3 миллиона пользователей установили вредоносное или рекламное ПО под видом браузерных расширений.
Для SOC это конкретный gap: расширения - слепая зона, которую атакующие уже эксплуатируют, а корреляционных правил для их мониторинга в большинстве корпоративных SIEM нет. Ниже - методология пентеста браузерных расширений, типичные уязвимости Chrome и Firefox расширений с кодом, и правила корреляции для detection.
Бизнес-логика: зачем атакуют расширения и чем это грозит компании
Браузерное расширение - это JavaScript-код с привилегированным доступом к DOM посещаемых сайтов, cookies, хранилищу и API браузера. Для атакующего это готовый плацдарм: не нужно обходить EDR или эксплуатировать уязвимость ОС - код уже работает внутри доверенного процесса. Расширение с permissionscookies + <all_urls> читает все cookies любого домена, включая HttpOnly cookies, недоступные через document.cookie из JS веб-страницы. Кража session cookie от SSO-портала эквивалентна компрометации учётной записи без пароля и без MFA. Просто вдумайтесь - без пароля и без MFA.Отдельный вектор - инсайдерская угроза. Сотрудник ставит расширение-стилер для выгрузки данных, а компрометация легитимного корпоративного расширения через supply chain даёт атакующему persistence на всех endpoints, где оно установлено (Browser Extensions, T1176.001, Persistence (Software Extensions)).
Типичные действия вредоносных расширений в терминах MITRE ATT&CK:
| Действие расширения | MITRE ATT&CK | Тактика |
|---|---|---|
| Закрепление через автообновление | Software Extensions (T1176) | Persistence |
| Перехват сессий на веб-страницах | Browser Session Hijacking (T1185) | Collection |
| Кража cookies авторизации | Steal Web Session Cookie (T1539) | Credential Access |
| Извлечение сохранённых паролей | Credentials from Web Browsers (T1555.003) | Credential Access |
| Запись нажатий клавиш | Keylogging (T1056.001) | Collection, Credential Access |
| Перехват буфера обмена | Clipboard Data (T1115) | Collection |
| Обфускация кода расширения | Obfuscated Files or Information (T1027) | Defense Evasion |
| Выполнение JS в контексте страниц | JavaScript (T1059.007) | Execution |
Архитектура расширений и поверхность атаки Chrome и Firefox
Контексты выполнения и manifest.json
Расширение состоит из трёх контекстов с разными привилегиями. Понимание их границ - фундамент анализа безопасности браузерных расширений.Background script (Service Worker в Manifest V3) - самый привилегированный контекст. Доступ к
chrome.tabs, chrome.cookies, chrome.storage, chrome.webRequest. В MV3 blocking webRequest заменён на declarativeNetRequest; webRequest доступен только в observe-режиме, за исключением расширений, установленных через enterprise policy (force-install) - для них blocking webRequest сохраняется. У declarativeNetRequest свои лимиты: 30k статических и 5k динамических правил. Здесь обрабатываются данные и уходят запросы к внешним серверам.Content script - выполняется в контексте веб-страницы, но в изолированном JavaScript-мире: доступ к DOM есть, к JS-переменным страницы - нет. Это ключевое ограничение и одновременно основной вектор атаки: content script работает с данными из недоверенного источника.
Popup - HTML/JS при клике на иконку. Отдельный контекст, общается с background через messaging API.
Всё определяется файлом manifest.json: permissions, content_scripts,
externally_connectable, web_accessible_resources, content_security_policy. Аудит манифеста - первый шаг пентеста. Всегда.Manifest V3 и безопасность - не панацея. На DEF CON 32 исследователи SquareX показали, что даже V3-расширения способны красть cookies, перехватывать live streams и вытаскивать учётные данные (по данным IIT Jammu, 2025). MV3 убрал
eval() и удалённые скрипты, но content scripts по-прежнему имеют полный доступ к DOM, а service worker сохраняет доступ к Extension API. Так что если кто-то скажет «мы на V3, нам не страшно» - не верьте.[Применимо: внутренний и внешний аудит. Chromium-based браузеры (Chrome, Edge, Brave) и Firefox используют общий формат WebExtensions - методология переносима между ними с поправкой на различия в API]
Методология тестирования на проникновение расширений браузера
Требования к окружению
- ОС: Windows 10/11, Linux, macOS - тестирование кроссплатформенно
- Браузер: Chrome 120+ или Firefox 115+ с включённым Developer Mode
- Инструменты: Chrome DevTools (встроен), Burp Suite Community/Pro для перехвата трафика
- RAM: минимум 4 ГБ, рекомендуется 8 ГБ при параллельной работе Burp Suite
- Сеть: online для загрузки расширения, далее offline-анализ распакованного кода
Пошаговый анализ
Шаг 1. Извлечение исходного кода. Расширения Chrome хранятся в формате.crx (по сути ZIP-архив). Windows: C:\Users\<user>\AppData\Local\Google\Chrome\User Data\Default\Extensions\<ID>\<version>. Linux: ~/.config/google-chrome/Default/Extensions/<ID>/<version>. Firefox: ~/.mozilla/firefox/<profile>/extensions/. Распаковываем - получаем manifest.json и JS-файлы.Шаг 2. Аудит manifest.json. Смотрим на критичные элементы:
permissionsиhost_permissions- какие API и домены доступныcontent_scriptsсmatches: ["[I]://[/I]/*"]или<all_urls>- запуск на всех сайтахexternally_connectable- может ли произвольный сайт слать сообщения расширениюweb_accessible_resources- файлы расширения, доступные из контекста веб-страницы (вектор fingerprinting)content_security_policy- наличие и строгость CSP
<all_urls> + cookies, webRequestBlocking, nativeMessaging, clipboardRead. По данным GitHub Security Lab, комбинация <all_urls> с cookies позволяет расширению читать все cookies любого домена, включая HttpOnly cookies, недоступные из JS веб-страницы.Шаг 3. Статический анализ JS. Grep-паттерны для поиска:
innerHTML, document.write(), eval(), Function() - потенциальные XSS-векторы; fetch() и XMLHttpRequest к внешним хостам - data leakage; chrome.runtime.onMessageExternal без валидации sender - insecure message passing; секреты в localStorage - insecure storage (OWASP A08:2021, Software and Data Integrity Failures).Шаг 4. Перехват трафика. Проксируем через Burp Suite. Проверяем: куда расширение шлёт данные, HTTPS или HTTP, передаются ли cookies/токены. POST-запросы от content scripts, которых нет в нормальном поведении сайта - маркер data exfiltration.
Шаг 5. Анализ хранилища. DevTools → Application → Storage. Проверяем
chrome.storage и localStorage на токены, пароли, API-ключи в открытом виде. По OWASP Browser Extension Vulnerabilities Cheat Sheet, localStorage вместо chrome.storage API для чувствительных данных - распространённая уязвимость (Insecure Storage). Встречается чаще, чем хотелось бы.Шаг 6. Тестирование message passing. Из DevTools Console отправляем сообщение:
chrome.runtime.sendMessage('<extension_id>', {payload: 'test'}). Если расширение принимает сообщения от произвольных отправителей - вектор Extension API Injection.Уязвимости Chrome расширений: типичные находки с примерами
XSS и content script уязвимости
Самая частая ошибка -innerHTML для вставки данных из DOM или пользовательского ввода. Пример из OWASP Browser Extension Vulnerabilities Cheat Sheet:
JavaScript:
// Уязвимый код в content script или popup
let userInput = document.getElementById('input').value;
document.getElementById('output').innerHTML = userInput; // XSSinnerHTML - классический DOM XSS. Mitigation: textContent вместо innerHTML, DOMPurify для санитизации, CSP с запретом unsafe-inline.Отдельный вектор - DOM-based Data Skimming (OWASP): расширение рендерит чувствительные данные (email, токены) прямо в DOM веб-страницы, где скрипты страницы их спокойно читают. Защита: отображать данные только в popup или side panel, не в DOM.
Insecure Message Passing и Extension API Injection
Background script, обрабатывающий внешние сообщения без проверки origin - прямой путь к Universal XSS:
JavaScript:
// Пример для Manifest V2 (в MV3 string-based code execution удалена из API)
chrome.runtime.onMessageExternal.addListener(
(request, sender, sendResponse) => {
// Нет проверки sender.url или sender.id
chrome.tabs.executeScript({code: request.code}); // MV2 only
}
);executeScript - в контексте любого домена, к которому у расширения есть доступ. Этот вектор актуален для Manifest V2; в Manifest V3 передача строки кода через executeScript заблокирована, однако UXSS остаётся возможным через chrome.scripting.executeScript с контролируемыми аргументами func/files. По исследованию GitHub Security Lab, это даёт UXSS, если расширение имеет permission на activeTab или <all_urls>.[Ограничения: XSS через content scripts не работает, если расширение не взаимодействует с DOM. Message passing exploitation требует, чтобы
externally_connectable был открыт или расширение использовало onMessageExternal. Против расширений без внешних listener'ов этот вектор нерелевантен]Detection: мониторинг расширений в SIEM и EDR
Базовая телеметрия для SOC
На управляемых корпоративных endpoints ни одно расширение не должно появляться без ведома SOC. Источники данных:- Chrome Enterprise / GPO: политики
ExtensionInstallBlocklistиExtensionInstallAllowlist- whitelist-режим - Файловая активность: Sysmon EventID 11 (FileCreate) в директории Extensions - появление нового manifest.json
- EDR: обращения процесса
chrome.exe/firefox.exeк нетипичным доменам, запись в нестандартные storage-области - DNS-логи: резолв доменов, инициированный процессом браузера, не входящих в корпоративный baseline
Правила корреляции
Алерт 1. Новое расширение вне whitelist. Триггер: Sysmon EventID 11 с путём[I]\Extensions\[/I]\manifest.json, extension ID не в approved-списке. Для EDR (CrowdStrike Falcon, SentinelOne, Elastic 8.x+) - FileCreate-события с аналогичным фильтром по пути. Покрывает T1176 - Software Extensions (Persistence) и инсайдерский сценарий установки стилера.Алерт 2. Расширение с критичными permissions. Периодический скрипт парсит manifest.json всех установленных расширений, сравнивает permissions с baseline. Флаги:
<all_urls>, cookies, webRequest, nativeMessaging, clipboardRead. Реализация: PowerShell/Python-скрипт по расписанию, результат - в SIEM как кастомный лог. Да, это костыль. Но пока ни один EDR-вендор не даёт эту телеметрию нативно - костыль работает.Алерт 3. Сетевая аномалия процесса браузера.
chrome.exe устанавливает соединение с доменом вне baseline (CDN, корпоративные ресурсы, известные сервисы). Корреляция: DNS-логи + netflow. POST-запросы с content-type application/json к неизвестным endpoints - маркер data exfiltration через расширение.Алерт 4. Массовое обращение к cookies (инсайдерский вектор). Процесс браузера за 60 секунд обращается к cookies более 10 уникальных доменов. Характерный паттерн для расширений, реализующих Steal Web Session Cookie (T1539). Для детекции нужен мониторинг обращений к файлу Cookies в профиле браузера: Windows Security EventID 4663 (object access auditing) с настроенным SACL на файл Cookies, либо EDR-телеметрия file read access.
Нюанс: SACL на файл Cookies генерирует high-volume noise при штатной работе chrome.exe. Фильтрация должна идти по access mask READ_DATA от процессов, отличных от chrome.exe, либо через EDR file access telemetry с аналогичным фильтром. Sysmon EventID 10 фиксирует доступ процесса к процессу, а не к файлам; EventID 11 - только создание файла. Современные Chrome хранят Cookies в
Network\Cookies; начиная с Chrome 127+ на Windows используется App-Bound Encryption (ABE) - ключ шифрования cookies защищён SYSTEM-level DPAPI и привязан к процессу chrome.exe, что серьёзно усложняет чтение Cookies сторонним процессом.IOC и маркеры вредоносных расширений
По данным «Лаборатории Касперского» (2022) и исследования IIT Jammu (2025):- Обфусцированный JS-код (T1027) - webpack/terser-обфускация допустима, но
String.fromCharCodeиatob()в цепочке сeval()- красный флаг - Обращение к C2 при первом запуске - домен не совпадает с заявленным функционалом
- Чтение DOM-элементов форм авторизации на банковских и корпоративных сайтах
- Перехват
chrome.webRequestдля модификации HTTP-заголовков (инъекция tracking-параметров, подмена cookies)
Инструменты для аудита безопасности browser extension
| Инструмент | Назначение | Ограничения | Статус |
|---|---|---|---|
| Chrome DevTools | Инспекция content scripts, storage, network, Source tab для отладки | Только Chromium-based, нет автоматизации | Встроен в Chrome, всегда актуален |
about:debugging (Firefox) | Инспекция WebExtensions в Firefox | Аналог DevTools, без extension-specific automation | Встроен в Firefox |
| Tarnish | Автоматический анализ permissions, CSP, entry points Chrome-расширений | Веб-сервис, не все расширения доступны | Проверить актуальность перед использованием |
| Burp Suite | Перехват сетевого трафика расширения | Нужна настройка прокси | Активно поддерживается PortSwigger |
| Retire.js | Обнаружение уязвимых JS-библиотек (OWASP A06:2021) | Только known CVE, не находит logic bugs | Активный проект, обновляется |
Чеклист аудита безопасности browser extension
За последний год я провёл аудит около двух десятков корпоративных расширений - от внутренних инструментов до публичных плагинов, одобренных IT-отделами «после проверки». В восьми случаях нашёл permissions overreach: расширение запрашивало
<all_urls> для функционала, которому хватило бы activeTab. В трёх - content scripts использовали innerHTML для вставки данных из API без санитизации. Ни один из этих кейсов не детектировался корпоративным SIEM, потому что расширения просто не входили в scope мониторинга SOC-команды. Ноль алертов. Тишина.Расширения живут в слепой зоне между endpoint security и web security. EDR видит процесс
chrome.exe, но не видит, что конкретное расширение отправляет POST с cookies на внешний сервер. SIEM получает DNS-логи, но не привязывает запрос к конкретному расширению. MV3 эту проблему не закрыл - DEF CON 32 подтвердил, что V3-расширения успешно крадут cookies и перехватывают сессии. Ни один EDR-вендор пока не даёт нативной телеметрии по активности отдельных расширений - приходится решать кастомными скриптами инвентаризации и правилами на уровне файловой системы.Пока SOC-команды не включат расширения в baseline - с whitelist-политиками, периодическим парсингом manifest.json и алертами на аномальные permissions - этот вектор останется открытым, и инсайдер или supply chain-атакующий будет его использовать. Если адаптируете правила мониторинга расширений под нестандартный SIEM-стек - на codeby.net коллеги делятся рабочими конфигурациями и разбирают свежие supply chain-кейсы в тематическом треде.
