Новость с SecurityLab (март 2026 года) показала любопытный приём: при нажатии F12 браузер отображает пустую страницу вместо обычного HTML/CSS/JS. Оказалось, такой «пустотой» злоумышленники маскируют вредоносный код, который активно работает в фоне. Для студентов ИТ-направлений это не просто курьёз, а сигнал: классические методы анализа кода через DevTools перестают работать. Значит, в дипломных проектах появляется новая область — исследование антиотладочных механизмов и способов их обнаружения. Разберём, как эту тему превратить в сильную ВКР, что изучать, какие метрики брать и как оформить работу по стандартам.
Веб-приложения всё чаще используют обфускацию, WebAssembly, детекторы открытых инструментов разработчика, подмену DOM, анти-debugging. Для будущего архитектора или разработчика это значит, что защита должна рассматриваться не как набор «магических» методов, а как инженерная задача: с анализом угроз, выбором контрмер и проверкой эффективности. ВКР на эту тему позволяет показать навыки работы с клиентской безопасностью и методологией исследований — именно этого ждут экзаменационные комиссии.
Предлагаю три рабочие темы. Для каждой указаны актуальность, цель, задачи и примерная структура — можно брать за основу и адаптировать под требования вашего вуза.
| Тема ВКР | Актуальность (связь со статьёй) | Цель | Задачи |
|---|---|---|---|
| Разработка модуля защиты клиентской части от анализа в DevTools | Скрытие логики становится трендом в борьбе с кражей кода и автоматизированными атаками | Спроектировать и реализовать модуль, который затрудняет статический и динамический анализ | 1. Классифицировать методы антиотладки. 2. Выбрать стек (WebAssembly + JS-обфускация). 3. Разработать модуль детекции DevTools. 4. Оценить производительность |
| Анализ эффективности антиотладочных механизмов в веб-приложениях | Статья демонстрирует, что «пустота» в F12 — лишь верхушка айсберга | Сравнить методы сокрытия кода и выработать рекомендации для защиты | 1. Собрать выборку методов. 2. Провести эксперименты. 3. Построить метрики. 4. Разработать рекомендации |
| Исследование уязвимостей клиентской части корпоративного портала | Маскировка кода — признак возможного вредоносного поведения | Выявить скрытые элементы и разработать методику обнаружения | 1. Изучить типичные уязвимости. 2. Написать скрипты для анализа. 3. Провести тестирование на стенде. 4. Оформить отчёт по ГОСТ |
Пример структуры для любой из этих тем:
В первом разделе нужно показать, что вы понимаете ландшафт решений. Обязательно сравните несколько технологий. Например:
| Метод | Сложность реализации | Скрытность | Влияние на производительность | Обнаружимость |
|---|---|---|---|---|
| Обфускация JavaScript | Низкая | Средняя | Низкое | Средняя — можно восстановить через beautify |
| WebAssembly (WASM) | Средняя | Высокая | Минимальное | Сложно читается, но бинарный анализ возможен |
| Детекция DevTools по таймингу/размеру окна | Низкая | Средняя | Нет | Обходится эмуляцией |
| Подмена DOM при открытом инспекторе | Низкая | Низкая | Нет | Заметна при динамическом анализе |
| Полная компиляция в нативный код (WASI) | Высокая | Очень высокая | Среднее | Требует специализированных инструментов |
В тексте главы не забудьте сослаться на стандарты. Для диплома по информационной безопасности это ГОСТ 34.601-2006 (стадии создания автоматизированных систем), ГОСТ 34.602-89 (техническое задание), а также ISO/IEC 25010 для качества продукта. В зависимости от профиля можно добавить OWASP ASVS как чек-лист требований к безопасности.
Здесь место для архитектуры вашего модуля или методики. Покажите, как именно вы реализуете защиту или анализ. Например, простейшая детекция DevTools может выглядеть так:
const detectDevTools = () => {
const threshold = 160;
const width = window.outerWidth - window.innerWidth;
const height = window.outerHeight - window.innerHeight;
if (width > threshold || height > threshold) {
// Подмена логики или вывод пустого экрана (как в статье)
document.body.innerHTML = '';
}
};
window.addEventListener('load', detectDevTools);Обязательно сделайте схемы двух типов:
Это удовлетворит требования многих методичек к наличию графических моделей.
Для защиты диплома критично показать цифры. Недостаточно сказать «мы сделали защиту». Измеряйте: RTO/RPO для аварийного восстановления, время реакции на инспекцию, количество скрытых элементов, сложность восстановления через beautifier, разницу в скорости загрузки с защитой и без.
Пример метрик в виде таблицы:
| Метрика | Без защиты | С защитой | Отклонение |
|---|---|---|---|
| Время загрузки страницы, мс | 840 | 920 | +9,5% |
| Время первого анализа кода через DevTools, сек | 3 | не удалось за 60 сек | +1900% |
| Количество читаемых JS-вызовов | 245 | 12 | −95% |
| RTO (восстановление после сбоя), мин | 15 | 15 | 0% |
Не забудьте провести нагрузочное тестирование. Оно покажет, не «съедает» ли защита ресурсы сервера. Используйте k6 или JMeter. Результаты можно оформить в виде графиков с подписью «Разработано автором».
Копая эту тему, вы прокачаете навыки, которые легко продать на собеседовании:
Ошибка 1. Подмена терминов: пишут «PaaS» вместо «SaaS» или называют любую обфускацию «шифрованием». Проверяйте определения, используйте глоссарий по ГОСТ.
Ошибка 2. Отсутствие метрик эффективности. Комиссия поверит только цифрам. Снимите замеры до/после, проведите 3–5 прогонов.
Ошибка 3. Игнорирование ГОСТ при оформлении ТЗ. Пропишите функциональные и нефункциональные требования в разделе 2.1 задания. Шаблон можно взять из ГОСТ 34.602-89.
Сложно, но не невозможно. В качестве ядра можно взять готовую библиотеку (например, js-obfuscator) и добавить свой модуль детекции. Главное, чтобы код был написан вами. Если не уверены в реализации — закажите консультацию или возьмите упрощённый вариант: исследование, а не разработку.
Зависит от программы. Для бакалавриата по ИВТ часто достаточно проектной документации и прототипа. Уточните на кафедре. Если код не нужен, сосредоточьтесь на аналитической главе и сравнительном тестировании чужих решений.
Используйте нотацию UML 2.5, не смешивайте типы диаграмм. Для диплома достаточно use case, activity и component. Подпишите каждую диаграмму («Рисунок 1 — Диаграмма вариантов использования») и сопровождайте текстовым описанием в работе.
Создайте собственный стенд: сгенерируйте несколько страниц с разными типами защиты (пустой body, детект F12, WASM). Также можно использовать общедоступные сайты из статьи или каталоги мер. Важно оформить разрешение на тестирование или использовать только свои ресурсы.
Не всегда получается совместить работу, учёбу и глубокое исследование. Если вы боитесь не успеть или застряли на проектной части, вспомните — ВКР на заказ делают уже давно. Главное выбрать тех, кто понимает вашу тему. Мы помогаем студентам с 2010 года и можем подсказать, как перестроить структуру, собрать метрики или оформить документацию по ГОСТ. Обращайтесь за бесплатной консультацией — обсудим вашу задачу, скажем, реально ли её осилить самостоятельно и где стоит подключить наставника.
Источник: Нажали F12 и увидели пустоту? Поздравляем, хакеры уже раскусили вас и стёрли все улики (опубликовано 2026-03-17)