Уязвимость 0.0.0.0 Day
7 августа Oligo Security опубликовали исследование об уязвимости во всех современных браузерах, которую назвали 0.0.0.0 Day. Информация об уязвимости была передана разработчикам браузеров в начале апреля. Рекомендую оригинальную статью к прочтению, особенно про первые зафиксированные в 2006 году атаки скриптов на веб-страницах на домашние роутеры.
Злоумышленник может выполнять запросы со страниц публичных frontend-приложений (через js или html-элементы) к сетевым службам / приложениям на устройстве пользователя (используя адрес 0.0.0.0 вместо localhost/127.0.0.1). Ранее считалось, что это запрещено. Уязвимость затрагивает все основные браузеры Chromium, Chrome, Safari, Firefox при работе в ОС Linux и macOS.
Почему так произошло?
В Chrome за контроль сетевых запросов frontend-приложения отвечает механизм PNA (Private Network Access), который на основании IP-адреса определял его тип (local, private, public). Например адреса, соответствующие 127.0.0.0/8, ::1/128 считались local. Проблема заключалась в том, что в PNA не было правила для 0.0.0.0, следовательно, адрес считался public и запросы разрешались. В других браузерах - схожая проблема в реализации функций выполнения сетевых запросов.
Что может сделать злоумышленник?
Скрипт может, перебирая различные порты на localhost понять, какие службы/ПО выполняются на устройстве пользователя. В случае наличия уязвимых служб или доступного без авторизации API - выполнить атаку или запрос к такому API. Исследователи описывают реально зафиксированные атаки на ПО Ray и Selenium Grid, приводящие к удаленному выполнению кода.
Когда исправят?
🔹Google планирует вносить исправления поэтапно с версии 128 до применения у всех пользователей к версии 133 (сейчас актуальная версия 127).
🔹Apple внесла исправления в код WebKit / Safari, исправления будут доставлены в одном из следующих апдейтов.
🔹Firefox ограничился исправлением спецификации Fetch, срок реализации неизвестен.
Теперь запросы на локальные и частные IP-адреса запрещены окончательно?
Нет. После полного внедрения PNA+CORS в случае, если запрос предназначен для private-адреса Chrome будет выполнять предварительный запрос OPTIONS (аналогично механизму CORS). Если целевой сервис ответит, что разрешает запросы для private (заголовок Access-Control-Allow-Private-Network: true), то Chrome выполнит сам запрос.
Почему говорят, что уязвимости 18 лет?
18 лет назад Google Chrome еще не существовал. 18 лет назад был создан первый репорт в баг-трекере Mozilla, когда пользователь обнаружил, что вредоносные js-скрипты на страницах атакуют домашний роутер по адресу 192.168.0.1. После этого были предприняты первые меры по блокировке запросов на внутренние адреса.
Что происходит сейчас?
С 1 августа фиксируется значительный рост📈 запросов со страниц на адрес 0.0.0.0. По оценке Google запросы осуществлялись со 100 тысяч публичных сайтов. Т.к. исправления выйдут не скоро, злоумышленники могут это использовать и внедрять вредоносные скрипты на скомпрометированные сайты или в JavaScript-библиотеки для распространения вредоносного кода через зависимости.
@FrontSecOps
7 августа Oligo Security опубликовали исследование об уязвимости во всех современных браузерах, которую назвали 0.0.0.0 Day. Информация об уязвимости была передана разработчикам браузеров в начале апреля. Рекомендую оригинальную статью к прочтению, особенно про первые зафиксированные в 2006 году атаки скриптов на веб-страницах на домашние роутеры.
Злоумышленник может выполнять запросы со страниц публичных frontend-приложений (через js или html-элементы) к сетевым службам / приложениям на устройстве пользователя (используя адрес 0.0.0.0 вместо localhost/127.0.0.1). Ранее считалось, что это запрещено. Уязвимость затрагивает все основные браузеры Chromium, Chrome, Safari, Firefox при работе в ОС Linux и macOS.
Почему так произошло?
В Chrome за контроль сетевых запросов frontend-приложения отвечает механизм PNA (Private Network Access), который на основании IP-адреса определял его тип (local, private, public). Например адреса, соответствующие 127.0.0.0/8, ::1/128 считались local. Проблема заключалась в том, что в PNA не было правила для 0.0.0.0, следовательно, адрес считался public и запросы разрешались. В других браузерах - схожая проблема в реализации функций выполнения сетевых запросов.
Что может сделать злоумышленник?
Скрипт может, перебирая различные порты на localhost понять, какие службы/ПО выполняются на устройстве пользователя. В случае наличия уязвимых служб или доступного без авторизации API - выполнить атаку или запрос к такому API. Исследователи описывают реально зафиксированные атаки на ПО Ray и Selenium Grid, приводящие к удаленному выполнению кода.
Когда исправят?
🔹Google планирует вносить исправления поэтапно с версии 128 до применения у всех пользователей к версии 133 (сейчас актуальная версия 127).
🔹Apple внесла исправления в код WebKit / Safari, исправления будут доставлены в одном из следующих апдейтов.
🔹Firefox ограничился исправлением спецификации Fetch, срок реализации неизвестен.
Теперь запросы на локальные и частные IP-адреса запрещены окончательно?
Нет. После полного внедрения PNA+CORS в случае, если запрос предназначен для private-адреса Chrome будет выполнять предварительный запрос OPTIONS (аналогично механизму CORS). Если целевой сервис ответит, что разрешает запросы для private (заголовок Access-Control-Allow-Private-Network: true), то Chrome выполнит сам запрос.
Почему говорят, что уязвимости 18 лет?
18 лет назад Google Chrome еще не существовал. 18 лет назад был создан первый репорт в баг-трекере Mozilla, когда пользователь обнаружил, что вредоносные js-скрипты на страницах атакуют домашний роутер по адресу 192.168.0.1. После этого были предприняты первые меры по блокировке запросов на внутренние адреса.
Что происходит сейчас?
С 1 августа фиксируется значительный рост📈 запросов со страниц на адрес 0.0.0.0. По оценке Google запросы осуществлялись со 100 тысяч публичных сайтов. Т.к. исправления выйдут не скоро, злоумышленники могут это использовать и внедрять вредоносные скрипты на скомпрометированные сайты или в JavaScript-библиотеки для распространения вредоносного кода через зависимости.
@FrontSecOps
npmgraph.js.org - сервис для просмотра дерева зависимостей в NPM-проектах. Чтобы построить граф зависимостей достаточно загрузить файл package.json или указать имя/версию интересующего модуля в NPM-репозитории. Кликая по узлам дерева, можно посмотреть различную информацию - размер, количество мейнтейнеров, частоту релизов, лицензии и другие метрики.
☁️⚠️ Сервис облачный, перед загрузкой файла package.json убедитесь, что в файле нет конфиденциальных данных / секретов. Можно удалить из файла все секции кроме "dependencies".
🌳✂️Сервис показывает максимальное число зависимостей, которые могут попасть в итоговый проект. Фактически, в результате работы механизма Tree Shaking (при его использовании) после анализа директив import/export и вызовов функций модулей, в итоговый файл-бандл будет добавлен только реально используемый код.
⚠️В то же время, данный перечень зависимостей не является полным. JS поддерживает динамический импорт внешних модулей при выполнении кода. Весь фактически исполняемый код возможно определить🔍 только на уровне браузера при выполнении реальных Use Case / E2E-сценариев.
@FrontSecOps
☁️
🌳✂️Сервис показывает максимальное число зависимостей, которые могут попасть в итоговый проект. Фактически, в результате работы механизма Tree Shaking (при его использовании) после анализа директив import/export и вызовов функций модулей, в итоговый файл-бандл будет добавлен только реально используемый код.
⚠️В то же время, данный перечень зависимостей не является полным. JS поддерживает динамический импорт внешних модулей при выполнении кода. Весь фактически исполняемый код возможно определить🔍 только на уровне браузера при выполнении реальных Use Case / E2E-сценариев.
@FrontSecOps
Please open Telegram to view this post
VIEW IN TELEGRAM
В субботу 5 октября в 10:55 (МСК) буду выступать на CyberCamp 2024.
Расскажу, как можно обнаружить вредоносное поведение js-кода, используя только инструменты браузера. Найдем скрытый в одной из транзитивных npm-зависимостей js-сниффер, крадущий данные из frontend-приложения Demo CRM.
Подключайтесь к бесплатной трансляции на сайте или площадках RuTube/VK. Актуальные ссылки на трансляции в канале @CYBERCAMP_ONLINE. Запись будет.
@FrontSecOps
Расскажу, как можно обнаружить вредоносное поведение js-кода, используя только инструменты браузера. Найдем скрытый в одной из транзитивных npm-зависимостей js-сниффер, крадущий данные из frontend-приложения Demo CRM.
Подключайтесь к бесплатной трансляции на сайте или площадках RuTube/VK. Актуальные ссылки на трансляции в канале @CYBERCAMP_ONLINE. Запись будет.
@FrontSecOps
2024.cybercamp.su
CyberCamp 2024
Практическая онлайн-конференция
для кибербезопасников. Проводим
третий год подряд!
для кибербезопасников. Проводим
третий год подряд!
Forwarded from DevSecOps Talks
Анализируем поведение браузерного JavaScript-приложения с помощью Chromium DevTools
Всем привет!
Завершает представление спикеров CyberCamp 2024 Михаил Парфенов, Application Security Architect!
Михаил поделится своим опытом: «JS-приложения, выполняемые в браузерах, содержат конфиденциальную информацию и часто используются для атак на пользователей. При этом браузер является слепой зоной для ИБ.
На кэмпе мы:
😵 Поговорим об актуальных рисках при разработке и эксплуатации JS-приложений
😵 Разберем несколько инцидентов, связанных с утечкой данных
😵 Проведем практический анализ поведения приложения с помощью встроенных инструментов браузера»
Рассказ Михаила, словно остросюжетный боевик! Ведь он расскажет, как обладая лишьцелеустремленностью, силой воли и карандашом «подручными» средствами можно реализовывать AppSec-практики!
P.S. Если вы хотите, чтобы мы сделали общий пост, в котором собрали всю информацию по докладам CyberCamp 2024, посвященных безопасной разработке и DevSecOps, пишите в комментариях 😊
Всем привет!
Завершает представление спикеров CyberCamp 2024 Михаил Парфенов, Application Security Architect!
Михаил поделится своим опытом: «JS-приложения, выполняемые в браузерах, содержат конфиденциальную информацию и часто используются для атак на пользователей. При этом браузер является слепой зоной для ИБ.
На кэмпе мы:
Рассказ Михаила, словно остросюжетный боевик! Ведь он расскажет, как обладая лишь
P.S. Если вы хотите, чтобы мы сделали общий пост, в котором собрали всю информацию по докладам CyberCamp 2024, посвященных безопасной разработке и DevSecOps, пишите в комментариях 😊
Please open Telegram to view this post
VIEW IN TELEGRAM
Всем привет! Рад сообщить, что я присоединился к команде DPA Analytics, и мы разработали и выпустили первый российский FAST-анализатор (Frontend Application Security Testing) в соответствии с концепцией, представленной на PHD 2. Подробнее о FAST-анализаторе расскажу в следующем посте...
Мы выпустили FAST-анализатор для безопасной разработки браузерных frontend-приложений (JavaScript/TypeScript), основанный на концепции Frontend Application Security Testing (FAST).
DPA FAST Analyzer по принципу "песочницы" для frontend-приложений анализирует поведение всех скриптов, обнаруживает вредоносный код🦠 в зависимостях по отклонениям от зафиксированного профиля поведения, отображает все каналы передачи данных, контролирует выполнение политик ИБ.
Сканирование производится в процессе автоматизированного выполнения Use Case-ов конкретного frontend-приложения. Быстро, без ложных срабатываний, эмулируя различные устройства (Desktop🪟 😁 , iOS🍏 , Android📱 ).
Инструмент может быть встроен в процесс безопасной разработки (SSDLC/DevSecOps ♾) или использоваться для периодического анализа поведения приложения в production (в этом случае также анализируется поведение сторонних js-сервисов - систем аналитики и т.п.)
Использование FAST-анализатора устраняет "слепую зону" в безопасности, характерную для frontend-приложений, позволяет выпускать приложения Secure by Design, оперативно выявлять инциденты и реагировать на них.
Буду рад показать для вас демо и провести пилот в вашей инфраструктуре! Оставляйте заявку на сайте или пишите мне в личные сообщения (@mkparfenov). Сделаем frontend безопасным вместе с подходом Frontend Application Security Testing!🔤 🔤 🔤 🔤
DPA FAST Analyzer по принципу "песочницы" для frontend-приложений анализирует поведение всех скриптов, обнаруживает вредоносный код
Сканирование производится в процессе автоматизированного выполнения Use Case-ов конкретного frontend-приложения. Быстро, без ложных срабатываний, эмулируя различные устройства (Desktop
Инструмент может быть встроен в процесс безопасной разработки (SSDLC/DevSecOps ♾) или использоваться для периодического анализа поведения приложения в production (в этом случае также анализируется поведение сторонних js-сервисов - систем аналитики и т.п.)
Использование FAST-анализатора устраняет "слепую зону" в безопасности, характерную для frontend-приложений, позволяет выпускать приложения Secure by Design, оперативно выявлять инциденты и реагировать на них.
Буду рад показать для вас демо и провести пилот в вашей инфраструктуре! Оставляйте заявку на сайте или пишите мне в личные сообщения (@mkparfenov). Сделаем frontend безопасным вместе с подходом Frontend Application Security Testing!
Please open Telegram to view this post
VIEW IN TELEGRAM
Frontend-фишинг в качестве начального вектора атаки Lumma Stealer
Злоумышленники различными способами направляли пользователей на созданные/скомпрометированные web-страницы, в которые был внедрен вредоносный js-код. Код может быть внедрен в frontend-приложение после взлома сервера либо в одной из зависимостей js-проекта (supply chain attack).
Скрипт производил редирект пользователя на страницу с поддельной Google reCAPTCHA, которая для доказательства "человечности" просила пользователя открыть утилиту Windows Run🪟 (Win + R), нажать Ctrl + V и Enter. При этом скрипт записывал в буфер обмена powershell-команду, загружавшую и выполняющую вредоносное ПО 🦠 .
Атака основана на том, что js-код активной вкладки браузера может записывать данные в буфер обмена без запроса дополнительных разрешений.
Интересно, что для записи вредоносной команды в буфер обмена злоумышленники использовали не современный Clipboard API, а устаревшую функцию Document.execCommand('copy'), которая до сих пор поддерживается браузерами.
Как FAST-анализатор поможет обнаружить подобные вредоносные действия?
При очередном сканировании🔎 , эмулируя действия пользователя, FAST:
🔹Обнаружит несанкционированное изменение js-кода.
🔹Обнаружит редирект на страницу злоумышленника (сетевой запрос на неразрешенный хост) (в случае если фальшивая капча показывается на внешней странице).
🔹Обнаружит iFrame (если капча показывается во фрейме).
🔹Обнаружит использование неразрешенной WebApi-функции Document.execCommand('copy').
🔹Показ капчи прервет/нарушит выполнение FAST-анализатором сценария сканирования - собранные метрики будут значительно отличаться от предыдущего скана - будет зафиксирована аномалия.
🔹Если вредоносные действия выполнялись только при определенных условиях, будут обнаружены дополнительные вызовы функций определения часового пояса, языка браузера, семейства браузера, размера окна и т.п.
@FrontSecOps
Злоумышленники различными способами направляли пользователей на созданные/скомпрометированные web-страницы, в которые был внедрен вредоносный js-код. Код может быть внедрен в frontend-приложение после взлома сервера либо в одной из зависимостей js-проекта (supply chain attack).
Скрипт производил редирект пользователя на страницу с поддельной Google reCAPTCHA, которая для доказательства "человечности" просила пользователя открыть утилиту Windows Run
Атака основана на том, что js-код активной вкладки браузера может записывать данные в буфер обмена без запроса дополнительных разрешений.
Интересно, что для записи вредоносной команды в буфер обмена злоумышленники использовали не современный Clipboard API, а устаревшую функцию Document.execCommand('copy'), которая до сих пор поддерживается браузерами.
Как FAST-анализатор поможет обнаружить подобные вредоносные действия?
При очередном сканировании
🔹Обнаружит несанкционированное изменение js-кода.
🔹Обнаружит редирект на страницу злоумышленника (сетевой запрос на неразрешенный хост) (в случае если фальшивая капча показывается на внешней странице).
🔹Обнаружит iFrame (если капча показывается во фрейме).
🔹Обнаружит использование неразрешенной WebApi-функции Document.execCommand('copy').
🔹Показ капчи прервет/нарушит выполнение FAST-анализатором сценария сканирования - собранные метрики будут значительно отличаться от предыдущего скана - будет зафиксирована аномалия.
🔹Если вредоносные действия выполнялись только при определенных условиях, будут обнаружены дополнительные вызовы функций определения часового пояса, языка браузера, семейства браузера, размера окна и т.п.
@FrontSecOps
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
SafeCode 2024 Autumn. Конференция по безопасности приложений
Анализ поведения как способ контроля безопасности frontend-приложений в DevSecOps | Доклад на SafeCode 2024 Autumn
Автоматизированный сбор и анализ Software Bill of Behavior (SBOB) позволяет обнаруживать вредоносное поведение / НДВ в зависимостях JS-проекта и выпускать приложения Secure by Design в рамках подхода Frontend Application Security Testing (FAST).
30 октября выступаю на SafeCode. Расскажу, как профиль поведения frontend-приложения, собираемый FAST-анализатором, и критерии критичности его составляющих позволяют с высокой точностью обнаруживать НДВ и вредоносные действия js-кода в зависимостях приложения
https://safecodeconf.ru/talks/defe452388e6453f8760935ec78f00b9/
https://safecodeconf.ru/talks/defe452388e6453f8760935ec78f00b9/
Сегодня на 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