Опубликовано: 17.09.2026 | Источник: SecurityLab (RSS)

Анализ «спящих» браузерных расширений для ВКР: методика обнаружения и измеримые метрики

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

Для выпускника ИТ-направления это не «страшилка из новостей», а готовая постановка задачи. Классические антивирусы и сигнатурные сканеры здесь почти бесполезны — вредоносного кода в момент установки физически нет. Значит, нужен собственный метод: анализ разрешений, поведенческий мониторинг, скоринг риска. Именно на таком разрыве между старым подходом и новой угрозой строится сильная, защищаемая ВКР.

Три темы ВКР, которые можно собрать из этого кейса

Тема 1. Метод выявления отложенной активации в браузерных расширениях

Актуальность: кейс «спящих» расширений показывает, что статическая сигнатура перестаёт работать как основной инструмент — код появляется уже после установки.

Цель: разработать метод и прототип, который помечает расширение как потенциально опасное до момента активации полезной нагрузки.

Задачи:

• проанализировать модель разрешений WebExtensions и выявить комбинации, характерные для отложенного запуска;
• построить признаки риска (запрашиваемый доступ к <all_urls>, offscreen-документы, удалённые конфиги, dynamic import);
• реализовать скоринг и проверить его на размеченной выборке расширений;
• оценить точность и ложноположительные срабатывания.

Структура: Глава 1 — обзор угроз и существующих детекторов; Глава 2 — проектирование архитектуры анализатора и модели признаков; Глава 3 — экспериментальная оценка, метрики, экономика внедрения.

Тема 2. Изолированный стенд для поведенческого анализа расширений

Актуальность: чтобы увидеть «пробуждение», нужно запустить расширение в контролируемой среде и перехватить обращения к API браузера. Без стенда диплом остаётся теоретическим.

Цель: спроектировать и развернуть стенд, воспроизводимый в CI, с полным журналированием действий расширения.

Задачи:

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

Структура: Глава 1 — анализ средств изоляции и стандартов; Глава 2 — архитектура стенда, схемы взаимодействия компонентов; Глава 3 — тестирование, метрики производительности, инструкция по развёртыванию.

Тема 3. Оценка риска цепочки поставок для каталогов расширений

Актуальность: массовость истории говорит о компрометации не одного автора, а целой группы пакетов — типичный сценарий атаки на цепочку поставок.

Цель: построить модель оценки риска расширения по метаданным каталога и косвенным признакам.

Задачи:

• сформировать набор признаков: смена владельца, резкий рост разрешений, обфускация, минификация без исходников;
• описать модель угроз по STRIDE и сопоставить с MITRE ATT&CK;
• реализовать сервис расчёта рейтинга риска;
• проверить модель на исторических данных и обосновать пороги.

Структура: Глава 1 — теория цепочек поставок и модель угроз; Глава 2 — проектирование сервиса и схемы данных; Глава 3 — валидация, метрики качества, оценка эффекта внедрения.

Аналитическая глава: как обосновать выбор подхода, а не «мне так удобнее»

Первая глава диплома чаще всего проваливается именно здесь. Студент пишет «для анализа выбран Python, потому что он удобный», и комиссия задаёт вопрос, на который нечего ответить. Сравнение должно опираться на критерии, измеримые и проверяемые. Ниже — каркас, который можно перенести в текст почти без изменений.

В тексте главы после таблицы обязательно нужен вывод в одно-два предложения: почему выбран гибридный вариант. Формулировка вида «статический анализ отсеивает явные случаи, динамический подтверждает гипотезу, скоринг снижает нагрузку на аналитика» звучит куда весомее, чем перечисление библиотек.

Нормативная база, о которой все забывают

Требования к системе оформляются по ГОСТ 34.602-89, и это не формальность: в нём есть разделы, которые напрямую касаются вашей темы — «Требования к защите информации» и «Требования к безопасности». Качество продукта удобно описывать через ISO/IEC 25010: функциональная полнота, защищённость, производительность, удобство сопровождения. Ссылка на эти документы в аналитической главе сразу поднимает уровень работы.

Проектная часть: архитектура, алгоритм, интеграция

Здесь статья превращается в конкретику. Представьте конвейер из четырёх ступеней — это и есть верхнеуровневая схема системы, которую вы нарисуете в главе 2.

• Сбор. Загрузчик обращается к каталогу, скачивает пакет расширения и складывает его в объектное хранилище с версионированием.
• Нормализация. Пакет распаковывается, извлекается манифест, строится дерево файлов, считаются хеши.
• Анализ. Статические правила проходят по исходникам и манифесту, параллельно расширение запускается в песочнице с перехватом вызовов.
• Скоринг и отчёт. Признаки сводятся в интегральную оценку, результат пишется в БД и отдаётся через API.

Что искать в манифесте

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

{
  "manifest_version": 3,
  "permissions": ["alarms", "offscreen", "scripting", "storage"],
  "host_permissions": ["<all_urls>"],
  "background": { "service_worker": "sw.js" },
  "content_scripts": [{ "matches": ["<all_urls>"], "js": ["inject.js"] }]
}

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

risk += 30 if "<all_urls>" in host_permissions
risk += 25 if "offscreen" in permissions
risk += 35 if remote_config_url not in trusted_domains and dynamic_import
score = normalize(risk)

Такой фрагмент отлично смотрится в приложении к диплому: он короткий, понятный и показывает логику, а не просто код.

Интеграция и развёртывание

Конвейер удобно собирать из независимых сервисов, общающихся через очередь сообщений. Это даёт вам законный повод написать в дипломе про масштабирование: если поток расширений вырос, добавляются воркеры анализа, а не переписывается вся система. Развёртывание описывайте через контейнеры и CI/CD-пайплайн: сборка образа, прогон тестов, публикация. Такой раздел закрывает сразу два требования — практическую значимость и технологичность.

Тестирование, метрики и доказательная база

Самый уязвимый для вопросов комиссии раздел. «Сканер нашёл 12 подозрительных расширений» — это не результат, это наблюдение. Нужны метрики, привязанные к размеченному набору данных: часть расширений заведомо безопасна, часть — известные образцы. Разметку можно вести вручную по публичным коллекциям образцов и каталогам; главное — зафиксировать принцип отбора и объём выборки.

Отдельно опишите отказоустойчивость стенда: RTO (время восстановления после сбоя) и RPO (объём потерянных данных) — даже приблизительные значения с обоснованием выглядят профессионально. Телеметрию собирайте через OpenTelemetry, храните в Prometheus, визуализируйте в Grafana: скриншоты дашбордов украсят приложение к работе.

Нагрузочное тестирование

Прогоните конвейер на 500–1000 расширениях и постройте график зависимости времени обработки от размера пакета. Зафиксируйте точку, где параллельные воркеры перестают давать прирост — это узкое место, и его честное описание в дипломе ценится выше, чем утверждение «система масштабируется бесконечно».

Чему вы научитесь на такой работе

• Проектировать многоступенчатые конвейеры обработки данных и обосновывать границы сервисов.
• Работать с моделью разрешений WebExtensions и понимать, почему декларация прав — самостоятельный источник признаков.
• Строить изолированные среды для анализа и подбирать уровень изоляции под задачу.
• Считать метрики качества детектора и защищать пороги срабатывания перед комиссией.
• Оформлять техническую документацию по ГОСТ 34 и описывать систему в терминах ISO/IEC 25010.

Вопросы, которые задают чаще всего

Источник: Сотни «спящих» расширений пробудились. Злоумышленники нашли способ сделать вредоносный код практически неуязвимым (опубликовано 2026-03-24)