Атаки на онлайн-платежи получили новый вектор: вредоносные скрипты начали использовать возможности WebRTC для обхода политики безопасности контента (CSP) и скрытого перехвата данных карт.
Речь идет о модифицированных вариантах так называемых web-скиммеров (вредоносного JavaScript-кода, внедряемого на страницы оформления заказа). Их задача прежняя: перехватить введенные пользователем платежные данные до отправки на сервер.
Использование WebRTC как канала эксфильтрации
Классические скиммеры передают украденные данные через HTTP-запросы на сторонние серверы. Именно такие запросы обычно и блокируются CSP, если политика настроена корректно.
Новый подход меняет сам механизм передачи. Вместо HTTP злоумышленники используют WebRTC DataChannel - двусторонний канал связи, изначально предназначенный для P2P-коммуникации в браузере.
Этот канал не подпадает под стандартные ограничения CSP, поскольку работает вне привычной модели загрузки ресурсов. В результате вредоносный код может:
установить WebRTC-соединение с удаленным узлом;
передать данные напрямую, минуя HTTP;
избежать детектирования средствами защиты, ориентированными на сетевые запросы.
Фактически WebRTC превращается в скрытый туннель для утечки данных.
Как внедряется вредоносный код
Сценарий атаки остается типичным для Magecart-подобных кампаний. Злоумышленники получают доступ к сайту интернет-магазина через уязвимости, компрометацию сторонних скриптов или учетных записей. После этого в страницу оплаты внедряется JavaScript, который отслеживает ввод в полях формы, перехватывает данные карты, включая номер, срок действия и CVV и сериализует данные в удобный для передачи формат.
Далее вместо отправки через fetch или XMLHttpRequest используется WebRTC-сессия.
Почему CSP больше не защищает
Content Security Policy создавалась как механизм ограничения источников загрузки ресурсов и сетевых запросов. Однако WebRTC работает иначе.
CSP контролирует:
загрузку скриптов;
выполнение inline-кода;
HTTP/HTTPS-запросы (fetch, XHR, WebSocket).
Но она не охватывает весь стек WebRTC, особенно на уровне peer-to-peer соединений и DataChannel. Это создает слепую зону, которую и используют атакующие.
Даже строгая CSP с ограничением доменов не предотвращает установку WebRTC-соединения, если выполнение JavaScript уже разрешено.
Усложнение детектирования
Использование WebRTC дает злоумышленникам сразу несколько преимуществ:
Во-первых, сетевой трафик выглядит иначе и не проходит через стандартные HTTP-инструменты мониторинга.
Во-вторых, соединения могут устанавливаться динамически, без явных доменных индикаторов.
В-третьих, передача данных может происходить фрагментированно или зашифрованно на уровне канала.
В итоге классические средства защиты, включая WAF и системы анализа логов, могут просто не увидеть утечку.
Практические меры защиты
Полностью закрыть этот вектор только настройками CSP невозможно, поэтому защита должна быть многоуровневой.
Ключевая мера это контроль целостности и источников JavaScript. Использование Subresource Integrity (SRI) и строгая политика загрузки скриптов снижают риск внедрения.
Дополнительно стоит:
минимизировать сторонние зависимости на страницах оплаты;
внедрять мониторинг изменений DOM и скриптов;
использовать поведенческий анализ на стороне клиента;
применять решения класса client-side security / browser isolation.
Также имеет смысл ограничивать использование WebRTC на уровне браузера или корпоративных политик, если он не требуется для работы приложения.
Рост сложности клиентских атак
Атаки с использованием WebRTC демонстрируют сдвиг в сторону более сложных техник на стороне клиента. Злоумышленники все чаще используют легитимные браузерные API не по назначению, превращая их в инструменты обхода защитных механизмов.
Это означает, что традиционные меры вроде CSP перестают быть достаточными сами по себе и требуют дополнения другими уровнями контроля.
Источник: HN