Статья Пентест браузерных расширений: методология анализа, уязвимости и detection для SOC

В конце 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 или эксплуатировать уязвимость ОС - код уже работает внутри доверенного процесса. Расширение с permissions cookies + <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. Смотрим на критичные элементы:

1. permissions и host_permissions - какие API и домены доступны
2. content_scripts с matches: ["[I]://[/I]/*"] или <all_urls> - запуск на всех сайтах
3. externally_connectable - может ли произвольный сайт слать сообщения расширению
4. web_accessible_resources - файлы расширения, доступные из контекста веб-страницы (вектор fingerprinting)
5. content_security_policy - наличие и строгость CSP

Красные флаги в permissions: <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:

// Уязвимый код в content script или popup
let userInput = document.getElementById('input').value;
document.getElementById('output').innerHTML = userInput; // XSS

Атакующий контролирует контент веб-страницы. Content script читает данные из DOM и вставляет их через innerHTML - классический 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:

// Пример для 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
  }
);

Внешний сайт отправляет сообщение расширению и заставляет выполнить произвольный JavaScript через 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​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

За последний год я провёл аудит около двух десятков корпоративных расширений - от внутренних инструментов до публичных плагинов, одобренных 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-кейсы в тематическом треде.