Слепое пятно iframe: новая эра атак на платежные шлюзы

Злоумышленники разработали изощренные методы обхода мер безопасности, предназначенных для защиты платежных iframe, что позволяет им красть данные банковских карт непосредственно со страниц оформления заказа. Основная угроза исходит от техники вредоносных наложений, когда поверх легитимной страницы создается пиксельно-точная поддельная форма. Атака нацелена не на сам iframe, а на содержащую его хост-страницу, что делает кражу данных невидимой для пользователя.
Слепое пятно iframe: новая эра атак на платежные шлюзы
Изображение носит иллюстративный характер

Реальным подтверждением этой угрозы является кампания «Stripe Skimmer», в ходе которой уже было скомпрометировано 49 интернет-магазинов. Атакующие используют упомянутые пиксельно-точные наложения для создания фальшивых платежных форм. Для проверки украденных номеров карт в реальном времени они задействуют устаревший API Stripe. Поскольку валидация происходит мгновенно, покупатель не замечает подмены, и транзакция, скорее всего, проходит в штатном режиме, в то время как данные его карты уже украдены.

Традиционные механизмы защиты, такие как заголовок X-Frame-Options, которому уже более десяти лет, и даже современная Политика безопасности контента (CSP), оказываются неэффективными против новых векторов атак. Злоумышленники научились обходить эти барьеры, используя пробелы в конфигурации безопасности и новые эксплойты.

Один из самых изощренных методов обхода — эксфильтрация данных на основе CSS, которая работает даже при строгой политике CSP. Атакующие внедряют на страницу CSS-код с селекторами атрибутов, нацеленными на поля ввода (input[value$="1"], input[value$="2"] и т. д.). Когда пользователь вводит номер карты, браузер для каждого символа пытается загрузить уникальное фоновое изображение с сервера злоумышленника (например, Таким образом, номер карты по одной цифре утекает на контролируемый хакерами сервер.

Другие методы обхода включают использование чрезмерно разрешающих настроек песочницы, таких как allow-same-origin + allow-scripts, которые сводят на нет всю защиту. Также эксплуатируются уязвимости в postMessage при использовании универсальных разрешений (wildcards) для origin и неверные конфигурации CORS (Cross-Origin Resource Sharing).

Новые нормативные требования заставляют компании пересматривать свой подход к безопасности. Стандарт PCI DSS 4.0.1 обязывает продавцов обеспечивать безопасность всей страницы, где вводятся платежные данные, а не только самого iframe. Особое внимание уделяется Требованию 6.4.6, которое прямо указывает на эту ответственность.

Для противодействия этим угрозам необходима многоуровневая стратегия защиты, основанная на принципе нулевого доверия. Первым шагом является внедрение строгой Политики безопасности контента (CSP). Это включает использование директив script-src 'nonce-abc123' 'strict-dynamic', object-src 'none', base-uri 'self', а также frame-ancestors 'none', которая является современной заменой X-Frame-Options. Доверенные домены, такие как stripe.com или , должны быть явно указаны в политике.

Ключевым элементом защиты является активный мониторинг DOM (Document Object Model) в реальном времени на предмет несанкционированных изменений. Подход, основанный на событиях, добавляет менее 0.1 мс задержки на каждое изменение DOM, в то время как менее эффективные методы опроса (polling) могут добавлять от 5 до 50 мс.

Внедрение полноценного решения для мониторинга, которое занимает около 10 часов, способно предотвратить атаки, средний ущерб от которых составляет 2 миллиона долларов. Командам с ограниченным опытом в JavaScript рекомендуется начать с внедрения CSP и использования внешних инструментов мониторинга. Командам с выделенными ресурсами безопасности следует реализовать комплексное решение, проверив его эффективность совместно со службой безопасности своего платежного провайдера.

Необходимо также обеспечить безопасность коммуникации через postMessage, всегда проверяя origin и структуру входящих сообщений для предотвращения подделки. Для всех внешних скриптов следует использовать механизм Subresource Integrity (SRI), который гарантирует, что их код не был изменен. Пассивная безопасность больше не является жизнеспособной стратегией.

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


Новое на сайте

20327Кости прерий: как истребление бизонов породило целую индустрию — и сама себя же уничтожила 20326Кто и зачем взламывает серверы Ollama и ComfyUI ради ключей от AWS? 20325Как злоумышленники спрятали командный сервер внутри блокчейна и почему его невозможно... 20324Брюссель заставляет Android делиться секретами с чужими ИИ-помощниками 20323WordPress: как два бага слились в одну критическую дыру, которую назвали wp2shell 20322Как китайские хакеры обманули DigiCert и украли сертификаты для подписи кода? 20321Что скрывается за уязвимостью, которую агентство США внесло в список активно используемых... 20320Автономные системы наступают быстрее, чем инфраструктура для управления ими: кто выиграет... 20319Почему в OpenSSL нашли дыру, съедающую память серверов, но не дали ей даже номер CVE? 20317SonicWall SMA 1000: как два бага превратили VPN-шлюз в бэкдор для атакующих 20316Может ли уязвимость в клиенте Zoom для Windows открыть доступ к чужому аккаунту без... 20315TELEPUZ: новый вредонос на C, который научился прятаться в Telegram, Steam и блокчейне... 20314Дома из дёрна: как исландцы триста лет прятались от холода под слоем земли и травы 20313Как один токен от чужого сервиса мог впустить злоумышленника в чужой аккаунт n8n?
Ссылка