Анализ уязвимости PolyShell в Magento для ВКР: от CWE-434 до защищаемых выводов
24 марта 2026 года компания Sansec сообщила об уязвимости PolyShell, затрагивающей все актуальные версии Magento Open Source и Adobe Commerce второй версии. Атакующий без аутентификации загружает на сервер исполняемые файлы — и получает либо удалённое выполнение кода, либо захват учётных записей через хранимую XSS. Для выпускника ИТ-направления это не новость «из мира», а готовый полигон: классический CWE-434, измеримые метрики, наглядная демонстрация и понятная практическая польза. Ниже — как превратить этот кейс в защищаемую ВКР, а не в пересказ пресс-релиза.
Вопросы, которые студент задаёт первым делом
Нужно ли поднимать настоящий Magento или хватит Docker-стенда?
Достаточно локального стенда на Docker: образы Magento Open Source 2.4.x + MariaDB + OpenSearch/Elasticsearch + Redis. Все версии Magento 2 актуальны для демонстрации, потому что уязвимость, по данным Sansec, затрагивает их целиком. В главе 3 вы описываете стенд как испытательный комплекс, фиксируете конфигурацию (версии, переменные окружения, ресурсы) — это требование воспроизводимости, без него результаты не принимаются.
Как считать эффективность защиты, если уязвимость уже закрывают патчем?
Вы оцениваете не «патч поставили / не поставили», а устойчивость системы к классу атак CWE-434. Метрики: доля заблокированных вредоносных загрузок (True Positive Rate), доля ложных срабатываний (False Positive Rate) на легитимных изображениях и PDF, время реакции WAF в миллисекундах, покрытие проверок статическим анализатором. Считаете до и после внедрения контрмер — получаете сопоставимую дельту, а это и есть «эффективность» в терминах ISO/IEC 25010 (Security → Confidentiality, Integrity).
Что взять в главу 1, чтобы это не выглядело как пересказ новости?
Новость — это только точка входа. В главе 1 вы разворачиваете её в анализ: место класса CWE-434 в OWASP Top 10 2021 (A04: Insecure Design и A05: Security Misconfiguration), вектор атаки по CVSS v3.1 с самостоятельным обоснованием оценки, модель угроз по STRIDE, DFD-диаграмму потоков данных Magento с точкой входа «загрузка файла». Три-четыре страницы такого анализа весят больше, чем двадцать страниц реферирования CVE-лент.
ГОСТ 34 или ГОСТ 19 — что выбрать для темы по безопасности?
Если ВКР описывает систему (модуль защиты, сервис мониторинга) — ГОСТ 34.601 и ГОСТ 34.602 на техническое задание. Если акцент на программном изделии и его документации — ГОСТ 19.201 (ТЗ) и ЕСПД. Смешивать их в одной работе без объяснения не стоит: нормоконтроль это ловит. Уточните на кафедре заранее — требование кафедры выше стандарта, который вам больше нравится.
Темы ВКР на базе кейса PolyShell
-
Тема 1. Разработка модуля контроля загрузки файлов для Magento 2
Актуальность: PolyShell эксплуатирует именно загрузку исполняемого файла без аутентификации; штатные механизмы платформы такой сценарий не покрывают.
Цель: снизить вероятность эксплуатации уязвимостей класса CWE-434 в интернет-магазине на Magento 2.
Задачи: 1) классифицировать векторы загрузки в Magento 2; 2) спроектировать плагин валидации (MIME, расширение, перекодирование полиглотов); 3) реализовать модуль и правила на уровне nginx; 4) провести DAST-тестирование и замерить метрики.
Структура: Глава 1 — анализ уязвимости PolyShell, OWASP Top 10 2021, CWE-434. Глава 2 — проектирование модуля (C4-диаграммы, спецификация по ГОСТ 34.602). Глава 3 — испытания на Docker-стенде, метрики, сравнение с WAF.
-
Тема 2. Методика выявления RCE-уязвимостей в e-commerce приложениях
Актуальность: случай PolyShell показывает, что уязвимость бьёт по всем актуальным версиям платформы сразу — значит, нужна не разовая заплатка, а повторяемый процесс обнаружения.
Цель: разработать методику выявления и приоритизации RCE-уязвимостей в интернет-магазинах.
Задачи: 1) сформировать каталог точек входа (загрузка файлов, десериализация, шаблонизаторы); 2) описать пайплайн SAST + DAST; 3) приоритизировать находки по CVSS v3.1; 4) проверить методику на стенде Magento.
Структура: Глава 1 — анализ угроз и MITRE ATT&CK-техник. Глава 2 — проектирование пайплайна DevSecOps, схемы в UML. Глава 3 — экспериментальная проверка, полнота обнаружения.
-
Тема 3. Оценка эффективности WAF при защите от эксплуатации PolyShell
Актуальность: многие магазины не могут быстро обновить платформу и закрываются сигнатурами WAF — но насколько это реально работает, никто не измерял на их конфигурации.
Цель: сравнить эффективность WAF-решений при отражении атак на загрузку файлов в Magento 2.
Задачи: 1) построить тестовый набор запросов (включая полиглот-файлы); 2) развернуть 2–3 WAF в режиме обнаружения; 3) измерить TPR/FPR и задержку; 4) сформулировать рекомендации по правилам.
Структура: Глава 1 — теория WAF и место в OWASP Top 10. Глава 2 — методика эксперимента. Глава 3 — результаты, таблицы метрик, экономическая оценка.
Как разложить кейс по главам
Глава 1: анализ, модель угроз, обоснование оценки
Начните с DFD-диаграммы Magento 2, где явно видны внешние сущности (покупатель, админ, платёжный шлюз) и накопители (media, БД). Точка входа «загрузка файла» обводится как граница доверия. Дальше — STRIDE по каждому потоку: подмена (S), раскрытие (I), отказ (D), повышение привилегий (E). Оценку по CVSS v3.1 считайте сами и приводите вектор строкой — это снимает половину вопросов на защите.
| Критерий | Как отражается в ВКР | Инструмент |
|---|---|---|
| Класс уязвимости | CWE-434, привязка к A04/A05 OWASP Top 10 2021 | Справочники CWE, OWASP |
| Оценка серьёзности | Вектор CVSS v3.1 с обоснованием каждой метрики | Калькулятор CVSS |
| Модель угроз | STRIDE + DFD на уровне контейнеров | draw.io, PlantUML |
| Последствия | RCE и захват учётных записей через хранимую XSS | Описание сценариев атак |
Глава 2: проектирование защиты
Здесь работает принцип «эшелонированная оборона»: валидация на уровне приложения, запрет исполнения на уровне веб-сервера, контроль целостности файлов. Архитектуру рисуйте в нотации C4 (уровни Context и Container) — комиссия любит, когда видно границы компонентов, а не абстрактные «модули». Если пишете ТЗ, оформляйте его по ГОСТ 34.602, а функциональные требования нумеруйте так, чтобы в главе 3 можно было сослаться на каждый пункт.
# nginx: запрет исполнения в каталогах загрузок Magento 2
location ~* ^/(media|pub/media|var)/.*\.(php|phtml|phar|php[0-9])$ {
deny all;
return 403;
}
location ~* ^/pub/static/.*\.(php|phtml|phar)$ { deny all; }
# отсечение полиглотов на уровне URI
if ($request_uri ~* "^/media/.*\.(phar|phtml|pht)$") { return 444; }
<?php
// Псевдокод плагина валидации загрузки (Magento 2, di.xml → beforeSave)
class UploadGuardPlugin
{
private const ALLOWED_MIME = ['image/jpeg', 'image/png', 'image/webp', 'application/pdf'];
public function beforeSave($subject, array $file): array
{
$mime = (new \finfo(FILEINFO_MIME_TYPE))->file($file['tmp_name']);
$ext = strtolower(pathinfo($file['name'], PATHINFO_EXTENSION));
if (!in_array($mime, self::ALLOWED_MIME, true)) {
throw new LocalizedException(__('MIME-тип не разрешён'));
}
if (in_array($ext, ['php', 'phtml', 'phar', 'pht'], true)) {
throw new LocalizedException(__('Расширение заблокировано'));
}
// ключевой шаг против полиглотов: перекодировать изображение
// через GD/Imagick, а не сохранять исходный бинарник
return [$file];
}
}
Глава 3: испытания, метрики, доказательства
Без чисел работа превращается в эссе. Эксперимент строится по схеме «до / после»: сначала фиксируете уязвимость на стенде, затем внедряете контрмеры и повторяете тот же сценарий. Все запросы и ответы сохраняйте в приложение — это доказательная база, к которой комиссия может обратиться.
| Метрика | Как измеряется | Что показывает |
|---|---|---|
| TPR (доля блокировок) | N успешных блокировок / N атак | Реальная защищённость |
| FPR (ложные срабатывания) | N отклонённых легитимных файлов / N легитимных | Цена защиты для бизнеса |
| Задержка обработки | Разница p95 до и после внедрения | Влияние на UX |
| Покрытие статического анализа | Найденные CWE-434 / все внесённые в код | Зрелость DevSecOps |
Чему вы научитесь
- Строить модель угроз по STRIDE и переносить её в DFD/C4 без потери смысла.
- Самостоятельно считать CVSS v3.1 и защищать оценку перед комиссией, а не копировать чужое число.
- Проектировать эшелонированную защиту: приложение, веб-сервер, WAF, мониторинг.
- Считать метрики безопасности и связывать их с характеристиками ISO/IEC 25010.
- Оформлять ТЗ и схемы по ГОСТ 34.602 / ГОСТ 19.201 так, чтобы нормоконтроль прошёл с первого раза.
Что проверить перед сдачей
- Задачи из введения дословно совпадают с пунктами глав и выводами — это проверяют первым.
- В главе 1 есть ссылка на первоисточник (Sansec / публикация от 2026-03-24), а не на пересказ.
- Все диаграммы подписаны, пронумерованы и упомянуты в тексте до их появления.
- Метрики в главе 3 имеют единицы измерения и способ получения, а не только итоговое число.
- Стенд описан так, что его можно воспроизвести: версии, образы, конфигурация.
- ТЗ и ЕСПД оформлены по выбранному стандарту единообразно во всей работе.
- Приложения с листингами и логами не дублируют основной текст и имеют оглавление.
Типичные ошибки
1. Пересказ новости вместо анализа. Студент открывает главу 1 фразой «компания Sansec обнаружила уязвимость» и на этом анализ заканчивается. Избежать просто: добавьте классификацию (CWE-434), модель угроз и обоснование CVSS-вектора — новость становится лишь иллюстрацией.
2. Демонстрация атаки на чужом стенде. Эксплуатация реальных магазинов — это не «практическая часть», а статья УК. Работайте исключительно на собственном локальном развёртывании, а в тексте прямо укажите, что эксперимент проводился в изолированном контуре.
3. Метрика ради метрики. Когда в главе 3 стоит «эффективность повысилась на 30%» без указания, что именно измерялось и на какой выборке, комиссия почти всегда просит пересчитать. Фиксируйте формулу, размер выборки и погрешность.
Если тема только формируется, а сроки уже поджимают — начните с консультации: разберём, какая из трёх тем ближе к вашей специальности и какие данные реально удастся собрать за оставшееся время. Стандартный объём работы — около 120 часов, включая стенд, эксперимент и оформление. Первая встреча бесплатная, помощь возможна с темой любой сложности.
Источник: RCE-уязвимость PolyShell угрожает магазинам на базе Magento (опубликовано 2026-03-24)
```