Сегодня на SOC Forum будем говорить об observability в frontend-приложениях. Приходите пообщаться или подключайтесь к трансляции
Компрометация библиотеки lottie-player (LottieFiles)
Lottie-player - популярная библиотека и сервис для создания и встраивания на сайты производительных векторных анимаций. Lottie-player загружается из npm-репозитория около 90 000 раз в неделю.
Supply chain attack
Злоумышленники провели фишинговую атаку на одного из разработчиков библиотеки и похитили токен🔑 от npm-репозитория. Далее 30 октября 2024 злоумышленники опубликовали 3 новых версии библиотеки (2.0.5, 2.0.6, 2.0.7) с добавленным вредоносным кодом 🦠 . Новые версии закэшировались сторонними CDN и отдавались по URL с тегом latest.
Вредоносный код показывал всплывающее окно🌐 с предложением подключить криптовалютный кошелек. У пользователей, которые кликали на кнопки и выполняли дальнейшие действия, похищалась криптовалюта, NFT и т.д. 🌐
Первые жалобы появились почти сразу. Разработчики удалили из npm версии либы с вредоносным кодом и выпустили версию 2.0.8 (равную по содержимому 2.0.4), а также обратились в CDN-ы для удаления закэшированных вредоносных версий.
Кто пострадал?
1. Frontend-приложения, в которых библиотека была подключена из сторонних CDN с тегом latest (очень плохая практика⚠️ ).
2. Приложения, при сборке которых из npm загружалась библиотека версий 2.0.5, 2.0.6, 2.0.7 в период 30-31 октября 2024.
Говорят, у кого-то украли криптовалюту на 723 000💲
При клике по кнопкам во всплывающем окне устанавливалось соединение WebSocket c хостом wss://castleservices01[.]com/ws
Как можно было обнаружить?
FAST-анализатор
При FAST-анализе🔎 (например, DPA FAST Analyzer), в результате отображенного всплывающего окна, произошло бы нарушение выполнения пользовательского UseCase. Cобранные метрики будут значительно отличаться от предыдущего скана - будет зафиксирована аномалия📈
Frontend Observability Platform (FOP)
Для обнаружения вредоносного поведения кода при нетипичных действиях пользователя (действия, которые невозможно смоделировать на этапе разработки) (например, клики по фишинговому баннеру🤒 ) используются решения класса FOP (например, DPA Frontend Observability Platform). В данной атаке FOP обнаружил бы в браузерах пользователей соединения WebSocket с неразрешенным хостом🤒
Совместное использование FAST и FOP делает frontend-приложения безопасными на всех этапах ЖЦ✔️
@FrontSecOps
Lottie-player - популярная библиотека и сервис для создания и встраивания на сайты производительных векторных анимаций. Lottie-player загружается из npm-репозитория около 90 000 раз в неделю.
Supply chain attack
Злоумышленники провели фишинговую атаку на одного из разработчиков библиотеки и похитили токен
Вредоносный код показывал всплывающее окно
Первые жалобы появились почти сразу. Разработчики удалили из npm версии либы с вредоносным кодом и выпустили версию 2.0.8 (равную по содержимому 2.0.4), а также обратились в CDN-ы для удаления закэшированных вредоносных версий.
Кто пострадал?
1. Frontend-приложения, в которых библиотека была подключена из сторонних CDN с тегом latest (очень плохая практика
2. Приложения, при сборке которых из npm загружалась библиотека версий 2.0.5, 2.0.6, 2.0.7 в период 30-31 октября 2024.
Говорят, у кого-то украли криптовалюту на 723 000
При клике по кнопкам во всплывающем окне устанавливалось соединение WebSocket c хостом wss://castleservices01[.]com/ws
Как можно было обнаружить?
FAST-анализатор
При FAST-анализе
Frontend Observability Platform (FOP)
Для обнаружения вредоносного поведения кода при нетипичных действиях пользователя (действия, которые невозможно смоделировать на этапе разработки) (например, клики по фишинговому баннеру
Совместное использование FAST и FOP делает frontend-приложения безопасными на всех этапах ЖЦ
@FrontSecOps
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Supply chain attack - solana/web3.js
Клиентская js-библиотека solana/web3.js используется в приложениях Solana dapps, работающих с блокчейном Solana. Библиотека загружается из npm более 300 000 раз в неделю.
Ситуация похожа на компрометацию lottie-player: фишинговая атака🤒 на разработчика 🔜 похищение токена от npm-репозитория 🔜 публикация 2 декабря 2024 года новых версий библиотеки с добавленным вредоносным кодом🦠 (версии 1.95.6, 1.95.7).
Вредоносный код похищал в приложении приватные ключи🔑 и отправлял на хост злоумышленника (https://sol-rpc[.]xyz) с помощью функции fetch()
Версии с вредоносным кодом были доступны в npm около 5 часов (3:20pm UTC - 8:25pm UTC 2 декабря). Разработчики признали факт компрометации и выпустили чистую версию 1.95.8
Сумма похищенных средств оценивается в 160 000💲
Отправка данных на неразрешенный хост - один из наиболее критичных признаков🤒 наличия вредоносного кода в js-зависимостях, выявляемых FAST-анализатором при выполнении поведенческого анализа frontend-приложений🔎
@FrontSecOps
Клиентская js-библиотека solana/web3.js используется в приложениях Solana dapps, работающих с блокчейном Solana. Библиотека загружается из npm более 300 000 раз в неделю.
Ситуация похожа на компрометацию lottie-player: фишинговая атака
Вредоносный код похищал в приложении приватные ключи
Версии с вредоносным кодом были доступны в npm около 5 часов (3:20pm UTC - 8:25pm UTC 2 декабря). Разработчики признали факт компрометации и выпустили чистую версию 1.95.8
Сумма похищенных средств оценивается в 160 000
Отправка данных на неразрешенный хост - один из наиболее критичных признаков
@FrontSecOps
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
JSON в GET-параметрах это сильно, пусть WAF-ам будет больно🥵
Всех с наступившим2️⃣ 0️⃣ 2️⃣ 5️⃣ !
Желаю всем нам безопасных приложений, легкого триажа, анализаторов без ложных срабатываний, зависимостей без вредоносного кода и прозрачной безопасной разработки frontend-приложений🖥 🛡 ☕️
@frontsecops
Всех с наступившим
Желаю всем нам безопасных приложений, легкого триажа, анализаторов без ложных срабатываний, зависимостей без вредоносного кода и прозрачной безопасной разработки frontend-приложений
@frontsecops
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from МедиаПраво
GA на сайтах + РКН
Вчера Алексей Березовой в своем канале Как устроены медиа отметил, что редакциям стали поступать требования от Роскомнадзора об удалении с сайтов Google Analytics.
Дополню. Не только СМИ, но и обычным компаниям. На скрине требование, которое получил интернет-магазин.
Сайты, на которых установлен счетчик, возможно, находит нейронка РКН в автоматическом режиме. К требованию РКН приложен скриншот исходного кода сайта, где Analytics выделен и подчеркнут.
Если сайт попадет под мониторинг Роскомнадзора, то требованием об удалении только одного счетчика, конечно, не ограничатся. Проверят абсолютно все, что касается обработки персональных данных на сайте: политики, согласия, формы.
Отмечу, что за такие истории не всегда сразу штрафуют. Наблюдаю лояльное отношение Роскомнадзора — предоставляется 10-дневный срок для устранения замечаний или выражения несогласия. Главное, не пропустить письмо с уведомлением.
➡️ Вот что еще нужно знать про метрики на сайтах
#ПерсональныеДанные #Интернет #СМИ
Вчера Алексей Березовой в своем канале Как устроены медиа отметил, что редакциям стали поступать требования от Роскомнадзора об удалении с сайтов Google Analytics.
Дополню. Не только СМИ, но и обычным компаниям. На скрине требование, которое получил интернет-магазин.
Сайты, на которых установлен счетчик, возможно, находит нейронка РКН в автоматическом режиме. К требованию РКН приложен скриншот исходного кода сайта, где Analytics выделен и подчеркнут.
Если сайт попадет под мониторинг Роскомнадзора, то требованием об удалении только одного счетчика, конечно, не ограничатся. Проверят абсолютно все, что касается обработки персональных данных на сайте: политики, согласия, формы.
Отмечу, что за такие истории не всегда сразу штрафуют. Наблюдаю лояльное отношение Роскомнадзора — предоставляется 10-дневный срок для устранения замечаний или выражения несогласия. Главное, не пропустить письмо с уведомлением.
#ПерсональныеДанные #Интернет #СМИ
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
РКН рассылает компаниям требование удалить с сайтов скрипт Google Analytics из-за незаконной трансграничной передачи персональных данных (ПД) пользователей
С 2023 года трансграничная передача ПД без уведомления Роскомнадзора запрещена⛔️
РКН использует риск-ориентированный подход🏓 (ПП N1046 от 29.06.2021) при проведении контрольных мероприятий. На уровень риска влияют группы тяжести потенциальных негативных последствий от нарушений.
Что влияет на группу тяжести?
🆘 Сбор ПД, с использованием БД, находящихся за пределами РФ.
🆘 Сбор ПД, с использованием иностранных программ и сервисов.
🆘 Трансграничная передача ПД на территорию иностранных государств.
Категория риска влияет на вероятность проведения/частоту контрольных мероприятий. К контрольным мероприятиям☁️ относятся не только плановые/внеплановые проверки, но и "наблюдения за соблюдением требований", другими словами, мониторинг сайтов/frontend-приложений🔎
Как проверяют?
Сотрудник РКН открывает сайт компании🖥 , в браузере в DevTools смотрит, какие скрипты размещены на странице, на вкладке Network смотрит, на какие хосты / в какие страны отправляются сетевые запросы. Затем этим данные сверяются с Политикой конфиденциальности📄, размещенной на сайте и всплывающими уведомлениями-согласиями на передачу ПД третьим лицам, трансграничную передачу, перечнем третьих лиц и т.д.
В случае несоответствия компании может быть направлено предостережение/требование, а при неисполнении проведена проверка/штраф🪙 и другие регуляторные риски для бизнеса 🚓 . Вероятно, этот процесс уже автоматизирован, поэтому стали рассылать массовые уведомления.
Проблема не только в Google Analytics
Существует множество внешних сервисов/скриптов, используемых на сайтах (Google Tag Manager, Roistat, Criteo, Google Ads и другие), отправляющих данные на зарубежные серверы. По результатам наших аудитов и пилотов FAST-анализатора мы видим, что даже российские системы аналитики иногда передают данные🪪 за пределы РФ.
Это касается только личных кабинетов/интернет-магазинов?
Нет. Даже если на вашем сайте (frontend-приложении) нет ПД в явном виде (ФИО, телефон, данные паспорта и т.д.), цифровой отпечаток браузера, идентификаторы записанные в cookie👍 , профиль поведения пользователя являются сведениями, относящимися к определяемому физическому лицу, и регулятор признает их персональными данными 🪪
Для снижения регуляторных и реальных рисков утечки ПД в компании должны быть внедрены:
1️⃣ Политика безопасности frontend-приложений (сайтов, личных кабинетов и т.д.)
2️⃣ Связка этой политики с Политикой обработки ПД и поддержкой актуальности согласий/политик на сайтах компании.
3️⃣ Процесс управления изменениями (согласование добавления на сайт новых скриптов, систем аналитики, счетчиков и т.д., согласование хостов/стран/получателей данных, отражение их в согласиях, политиках на сайте).
4️⃣ Инструмент для контроля и уведомления об инцидентах. Любые политики бессмысленны без контроля. Ручной анализ frontend-приложений имеет низкую достоверность и является весьма трудозатратным. Для эффективного контроля можно использовать DPA FAST Analyzer.
FAST-анализатор:
✅ Проводит глубокую инвентаризацию всех скриптов/систем аналитик в рантайме браузера 🟡
✅ Отображает историю изменений скриптов для ретроспективного анализа
✅ Обнаруживает все отправки данных на сторонние серверы (системы аналитики и другие)
✅ Применяет к обнаруженным результатам политику по принципу белого списка (все, что не согласовано с ИБ, юристами, комплаенс - является инцидентом). Можно контролировать, на какие хосты/страны отправляются данные
✅ Уведомляет об обнаруженных инцидентах 🆘
✅ Может использоваться как в DevSecOps в качестве Security Gate, так и для сканирования frontend-приложения (сайта, личного кабинета, CRM, HRM и т.п.) в продакшене
Напишите мне📱 , мы проведем для вас пилот DPA FAST Analyzer, покажем всё, что происходит на сайте/frontend-приложении, обнаружим трансграничные передачи данных для предотвращения утечек и штрафов РКН 🛡
@FrontSecOps
С 2023 года трансграничная передача ПД без уведомления Роскомнадзора запрещена⛔️
РКН использует риск-ориентированный подход
Что влияет на группу тяжести?
Категория риска влияет на вероятность проведения/частоту контрольных мероприятий. К контрольным мероприятиям
Как проверяют?
Сотрудник РКН открывает сайт компании
В случае несоответствия компании может быть направлено предостережение/требование, а при неисполнении проведена проверка/штраф
Проблема не только в Google Analytics
Существует множество внешних сервисов/скриптов, используемых на сайтах (Google Tag Manager, Roistat, Criteo, Google Ads и другие), отправляющих данные на зарубежные серверы. По результатам наших аудитов и пилотов FAST-анализатора мы видим, что даже российские системы аналитики иногда передают данные
Это касается только личных кабинетов/интернет-магазинов?
Нет. Даже если на вашем сайте (frontend-приложении) нет ПД в явном виде (ФИО, телефон, данные паспорта и т.д.), цифровой отпечаток браузера, идентификаторы записанные в cookie
Для снижения регуляторных и реальных рисков утечки ПД в компании должны быть внедрены:
FAST-анализатор:
Напишите мне
@FrontSecOps
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Forwarded from Kaspersky
Эксперты Kaspersky GReAT обнаружили уязвимость нулевого дня в Google Chrome, которая позволяла атакующим обходить защиту браузера и заражать устройства буквально одним кликом. Всё, что нужно было жертве — просто открыть ссылку из письма.
Наши исследователи передали всю информацию Google, и 25 марта вышел патч, закрывающий уязвимость. Но кто стоял за атакой, почему эта кампания получила название Operation ForumTroll и какие ещё детали мы нашли?
Больше подробностей – в разборе на SecureList
Please open Telegram to view this post
VIEW IN TELEGRAM
Frontend-фишинг с использованием JS Notification / Push API
Эти API предоставляют js-коду📱 возможность показывать нативные уведомления браузера на устройстве пользователя. Push API (в отличии от Notification API) может показывать уведомления даже при закрытой вкладке браузера ⚠️ , а на мобильных устройствах даже при закрытом браузере, поэтому рассмотрим именно его.
Исходные данные
Наше frontend-приложение уже запрашивало разрешение на показ уведомлений либо запросит, и пользователи согласятся (доверяют нашей компании).
В случае с мобильными устройствами пользователи добавили наше web-приложений на экран "Домой", что дает web-приложению права PWA (progressive web app), в том числе права на отправку push-уведомлений.
Предположим, что в ваш проект попал вредоносный js-код (с новыми версиями зависимостей, в результате компрометации сервера, сгенерирован "плохой" нейросетью и т.д.), а именно в код Service Worker (требование для вызова Push API, для Notification API в любое место в js-коде).
Злоумышленник получает возможность подключиться к своему серверу push-уведомлений и показывать пользователю нативные уведомления с любой картинкой/текстом/возможностью при клике редиректить пользователя на любой сайт⚠️ . Это открывает безграничные возможности для фишинга 🤒
⚠️ С вашего счета произведен перевод денег..
⚠️ Заказ № 123456 оформлен, сумма 14 793 руб., дата доставки..
⚠️ Обнаружен вирус на устройстве, выберите действие..
⚠️ Ваш почтовый ящик заблокирован..
⚠️ Кто-кто входит в ваш аккаунт..
Далее - кража учетных данных🪪 , загрузка вредоносного вложения с эксплойтом 💣 и т.п.
На Desktop и Android в push-уведомлении можно показать любую картинку (логотип банка, мессенджера, популярного приложения). В iOS всегда будет отображаться иконка нашего сайта.
Если неквалифицированные пользователи / люди в возрасте доверяют баннерам "про обновление антивируса" на сайтах с кулинарными рецептами, то нативным уведомлениям на мобильном устройстве могут поверить даже опытные пользователи.
Злоумышленники "хотят" наш frontend больше💰 , чем мы думаем… А уязвимости браузеров 📱 🌐 делают frontend-приложения идеальной точкой проникновения на устройства пользователей.
Как защититься?
🔹Контролировать использование WebAPI в frontend-приложении: Service Worker API, Push API, Notification API
🔹Контролировать целостность js-кода, включая код Service Worker
🔹Проводить инвентаризацию js-кода, включая динамически загружаемый, в runtime браузера при выполнении основных E2E-сценариев
🔹Контроль при каждом релизе и периодически в продакшене + реагирование
@FrontSecOps
Эти API предоставляют js-коду
Исходные данные
Наше frontend-приложение уже запрашивало разрешение на показ уведомлений либо запросит, и пользователи согласятся (доверяют нашей компании).
В случае с мобильными устройствами пользователи добавили наше web-приложений на экран "Домой", что дает web-приложению права PWA (progressive web app), в том числе права на отправку push-уведомлений.
Предположим, что в ваш проект попал вредоносный js-код (с новыми версиями зависимостей, в результате компрометации сервера, сгенерирован "плохой" нейросетью и т.д.), а именно в код Service Worker (требование для вызова Push API, для Notification API в любое место в js-коде).
Злоумышленник получает возможность подключиться к своему серверу push-уведомлений и показывать пользователю нативные уведомления с любой картинкой/текстом/возможностью при клике редиректить пользователя на любой сайт
Далее - кража учетных данных
На Desktop и Android в push-уведомлении можно показать любую картинку (логотип банка, мессенджера, популярного приложения). В iOS всегда будет отображаться иконка нашего сайта.
Если неквалифицированные пользователи / люди в возрасте доверяют баннерам "про обновление антивируса" на сайтах с кулинарными рецептами, то нативным уведомлениям на мобильном устройстве могут поверить даже опытные пользователи.
Злоумышленники "хотят" наш frontend больше
Как защититься?
🔹Контролировать использование WebAPI в frontend-приложении: Service Worker API, Push API, Notification API
🔹Контролировать целостность js-кода, включая код Service Worker
🔹Проводить инвентаризацию js-кода, включая динамически загружаемый, в runtime браузера при выполнении основных E2E-сценариев
🔹Контроль при каждом релизе и периодически в продакшене + реагирование
@FrontSecOps
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Сегодня на Территории безопасности 2025 в Москве модерирую секцию "Атаки на вендоров ПО: Как контролировать цепочку поставок" и выступаю с докладом:
Браузер пользователя - идеальное место для кражи данных и атак. Как обнаружить утечки там, где WAF не видит? Или остановим Supply Chain атаки на фронтенде
Обсудим:
🔹Как вредоносный js-код может попасть в приложение📱 ?
🔹Как обнаружить вредоносные действия в "слепой зоне" - браузере пользователя📱
🔹Как предотвратить Supply Chain атаки в frontend-приложениях🛡 ?
Кто тоже здесь, приходите в 16:10 в Зал 2 (PRO Безопасность подрядчиков)
Браузер пользователя - идеальное место для кражи данных и атак. Как обнаружить утечки там, где WAF не видит? Или остановим Supply Chain атаки на фронтенде
Обсудим:
🔹Как вредоносный js-код может попасть в приложение
🔹Как обнаружить вредоносные действия в "слепой зоне" - браузере пользователя
🔹Как предотвратить Supply Chain атаки в frontend-приложениях
Кто тоже здесь, приходите в 16:10 в Зал 2 (PRO Безопасность подрядчиков)
Please open Telegram to view this post
VIEW IN TELEGRAM
31 марта 2025 перешли в статус обязательных требования PCI DSS 4.0.1 для frontend-приложений
Обязательность выполнения требований актуальной версии PCI DSS указана в Программе безопасности ПС «Мир» / НСПК.
🔹 6.4.3 Все скрипты платежных страниц, которые загружаются и выполняются в браузере пользователя, управляются следующим образом:
- Актуальная инвентаризация всех скриптов с письменным обоснованием бизнес-необходимости каждого из них.
- Реализован метод подтверждения авторизации и целостности каждого скрипта.
🔹 11.6.1 Обнаружение и реагирование на несанкционированное изменение платежных страниц:
- Контроль изменений на платежных страницах.
- Контроль изменений HTTP заголовков (в том числе Content Security Policy (CSP)).
- Оповещение персонала о несанкционированных изменениях.
🔹 Требования также применяются к web-страницам, на которых встроен сторонний iframe c формой оплаты TPSP/платежного процессора.
Использование CSP не может полноценно выполнить эти требования и обеспечить безопасность пользователей⚠️
Точнее сказать выполнить требования для аудитора то может, по принципу "заголовок CSP с хэшами скриптов есть, бизнес-обоснования записываем в блокноте📝 , каждый день проверяем глазами 👁 ..." 😄 (наотъе .. кто здесь 😂? только для галочки аудитора ☑️ ).
Но мы ведь не из таких ... 😎 Мы знаем, что требования появляются не просто так, а для снижения рисков от реальных угроз: js-снифферов, frontend-фишинга, Supply Chain Attack и т.д.
Файл-бандл frontend-приложения📱 включает все зависимости (десятки-сотни opensource-библиотек) и изменяется при каждом релизе приложения ➡️ изменяется хэш файла ➡️ меняем заголовок CSP. Бизнес-обоснование? "Это главный скрипт приложения". Кто-то проверял, что в новые версии зависимостей не был встроен js-сниффер? Нет. 🤨 Но формально требования PCI DSS выполнены ☑️
Кстати, НКЦКИ требует именно проверку скриптов на вредоносные действия после любых изменений, а не только контроль целостности.
Допустим разрешенные хэши скриптов в CSP указали, а вот запретить eval() забыли (формально, не требуется). Вредоносный код в зависимости хранит пейлоад в base64➡️ извлекает код сниффера ➡️ выполняет через eval() ➡️ данные карт клиентов 💳 похищаются прямо в браузере пользователя в "слепой зоне" для WAF, NGFW, DLP... 🤨
Даже при самой строгой CSP попавший на страницу вредоносный код может отправить данные на хост злоумышленника через механизм навигации.
В разъяснительной части PCI DSS 4.0.1, сказано: "Единственное место, где можно обнаружить изменения и признаки вредоносной активности — это браузер пользователя, где страница полностью собрана и выполнен весь JavaScript-код".
Без глубокого анализа поведения js-кода в реальном браузере📱 / frontend-sandbox (например, DPA FAST Analyzer) невозможно провести достоверную инвентаризацию скриптов и обнаружить утечки данных в frontend-приложении.
PCI DSS 4.0.1 - первый стандарт, в явном виде зафиксировавший необходимость обеспечения безопасности frontend-ов и должен являться best practice для всех компаний✅
Давайте защищать🛡 наших пользователей, их данные и репутацию компании, а не делать что-то только для "галочки" аудитора ☑️
@FrontSecOps
Обязательность выполнения требований актуальной версии PCI DSS указана в Программе безопасности ПС «Мир» / НСПК.
🔹 6.4.3 Все скрипты платежных страниц, которые загружаются и выполняются в браузере пользователя, управляются следующим образом:
- Актуальная инвентаризация всех скриптов с письменным обоснованием бизнес-необходимости каждого из них.
- Реализован метод подтверждения авторизации и целостности каждого скрипта.
🔹 11.6.1 Обнаружение и реагирование на несанкционированное изменение платежных страниц:
- Контроль изменений на платежных страницах.
- Контроль изменений HTTP заголовков (в том числе Content Security Policy (CSP)).
- Оповещение персонала о несанкционированных изменениях.
🔹 Требования также применяются к web-страницам, на которых встроен сторонний iframe c формой оплаты TPSP/платежного процессора.
Использование CSP не может полноценно выполнить эти требования и обеспечить безопасность пользователей
Точнее сказать выполнить требования для аудитора то может, по принципу "заголовок CSP с хэшами скриптов есть, бизнес-обоснования записываем в блокноте
Но мы ведь не из таких ... 😎 Мы знаем, что требования появляются не просто так, а для снижения рисков от реальных угроз: js-снифферов, frontend-фишинга, Supply Chain Attack и т.д.
Файл-бандл frontend-приложения
Кстати, НКЦКИ требует именно проверку скриптов на вредоносные действия после любых изменений, а не только контроль целостности.
Допустим разрешенные хэши скриптов в CSP указали, а вот запретить eval() забыли (формально, не требуется). Вредоносный код в зависимости хранит пейлоад в base64
Даже при самой строгой CSP попавший на страницу вредоносный код может отправить данные на хост злоумышленника через механизм навигации.
В разъяснительной части PCI DSS 4.0.1, сказано: "Единственное место, где можно обнаружить изменения и признаки вредоносной активности — это браузер пользователя, где страница полностью собрана и выполнен весь JavaScript-код".
Без глубокого анализа поведения js-кода в реальном браузере
PCI DSS 4.0.1 - первый стандарт, в явном виде зафиксировавший необходимость обеспечения безопасности frontend-ов и должен являться best practice для всех компаний
Давайте защищать
@FrontSecOps
Please open Telegram to view this post
VIEW IN TELEGRAM
Завтра (25 апреля) в 13:15-13:40 (МСК) на AppSecFest 2025 (Алматы, Казахстан) выступаю с докладом "Frontend Application Security Testing (FAST). Задачи подхода и место в DevSecOps/SSDLC". Приходите в зал Security или подключайтесь к бесплатной трансляции на сайте https://appsecfest.kz
👍1
Frontend SSDLC и уязвимости браузеров
29 апреля 2025 вышла версия (136.0.7103.59) Google Chrome с исправлением CVE-2025-4096 -⚠️ high-уязвимости в Chrome 📱 и Chromium-based браузерах. Уязвимость класса Heap buffer overflow в движке HTML. Эксплуатация уязвимости (создание на веб-странице специального сформированного фрагмента) может привести к выполнению произвольного кода на устройстве пользователя. За обнаружение уязвимости исследователю было выплачено 5000$ 💰
Это уже не первая опасная уязвимость в Chromium в этом году.
Заражение устройств пользователей⌨️ через эксплуатацию уязвимостей браузеров - один из способов монетизации злоумышленниками внедрения вредоносного js-кода в frontend-приложения. Вредоносный код может попасть в js-приложение со сторонними библиотеками (npm-зависимости ✈️ ) или через внешние js-сервисы 📱 (системы аналитики, счетчики, тег-менеджеры и т.п.).
Внедрение вредоносного js-кода в популярное приложение/сайт дает возможность заразить значительное количество устройств пользователей, а также проникать в корпоративные сети. Через frontend-приложения возможно заразить устройства даже во внутренних сетях без интернета⚠️
Например, вы устанавливаете новую версию внутрисетевого приложения (ERP, CRM, SIEM, WAF, VM или любое другое ПО с браузерным UI, даже SAST, DAST, SCA, веб сейчас повсюду), а вендор ПО не проверяет frontend-часть на вредоносное поведение (ограничивается только проверкой версий зависимостей по базам известных уязвимостей).
Далее вредоносный js-код, при открытии пользователем страницы🖥 :
1. эксплуатирует уязвимость браузера🌐
2. имитирует скачивание файла (pdf, docx, ...) с эксплойтом для офисного ПО💣
3. показывает фишинговые уведомления🤒 ⌨️
В итоге: заражение устройства пользователя в корпоративной сети без интернета и дальнейшее развитие атаки🤒
Анализируйте поведение ваших frontend-приложений🔍 (целью являются ваши пользователи!) и требуйте этого от поставщиков используемого ПО. Даже внутрисетевого⚠️
@FrontSecOps
29 апреля 2025 вышла версия (136.0.7103.59) Google Chrome с исправлением CVE-2025-4096 -
Это уже не первая опасная уязвимость в Chromium в этом году.
Заражение устройств пользователей
Внедрение вредоносного js-кода в популярное приложение/сайт дает возможность заразить значительное количество устройств пользователей, а также проникать в корпоративные сети. Через frontend-приложения возможно заразить устройства даже во внутренних сетях без интернета
Например, вы устанавливаете новую версию внутрисетевого приложения (ERP, CRM, SIEM, WAF, VM или любое другое ПО с браузерным UI, даже SAST, DAST, SCA, веб сейчас повсюду), а вендор ПО не проверяет frontend-часть на вредоносное поведение (ограничивается только проверкой версий зависимостей по базам известных уязвимостей).
Далее вредоносный js-код, при открытии пользователем страницы
1. эксплуатирует уязвимость браузера
2. имитирует скачивание файла (pdf, docx, ...) с эксплойтом для офисного ПО
3. показывает фишинговые уведомления
В итоге: заражение устройства пользователя в корпоративной сети без интернета и дальнейшее развитие атаки
Анализируйте поведение ваших frontend-приложений
@FrontSecOps
Please open Telegram to view this post
VIEW IN TELEGRAM