Как карточные данные могут украсть еще до платежа: что нужно знать

Добавьте Finance.ua в избранные источники Google

Web skimming, или e-skimming — это перехват карточных и других персональных данных при взаимодействии покупателя с сайтом. Вместо физической накладки на банкомат злоумышленники используют программный код.

Заказ оплачен, деньги поступили, покупатель получил подтверждение. Для магазина все смотрится нормально. Однако реквизиты карты могли попасть к злоумышленникам еще во время ввода — через вредоносный код на сайте. Такая атака называется web skimming.

Об этом пишет WayForPay, мы выбрали основное.

Как данные похищают

По объяснению американского агентства кибербезопасности CISA, такой код может попасть на сайт через уязвимости платформы, похищенные учетные данные администратора или скомпрометированный сторонний сервис. Информация перехватывается при вводе и передается на сервер нападающих.

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

Место для вашей рекламы

Это иллюстративный сценарий, а не описание инцидента. Поддельные встроенные формы и всплывающие окна, имитирующие настоящий checkout, описаны в отчете Visa об угрозах.

Другой вариант — незаметное копирование данных с полей, к которым вредоносный скрипт имеет доступ. В обоих случаях успешная оплата не доказывает, что реквизиты не были похищены раньше.

Реальный кейс: все думали, что безопасностью занимается кто-то другой

Показательный случай описал британский регулятор ICO о магазине Direct Clothing. В августе 2021 года покупатель сообщил о мошеннических операциях с картой после использования сайта компании.

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

Важная деталь: компания считала, что за безопасность и обслуживание сайта отвечает IT-подрядчик, однако, фактически это было не так.

Для предпринимателя этот кейс начинается с простого вопроса: кто именно обновляет плагины, согласовывает изменения на странице оплаты и реагирует на подозрительную активность? Ответ должен быть закреплен в договоренностях с подрядчиком. Формулировки «сайтом занимается разработчик» недостаточно: создание магазина и его дальнейшая защита — разные задачи.

Что показывают проверки платежных страниц

По результатам SecurityMetrics за 2026 год, в 67% проверок платежных страниц сервисом Shopping Cart Inspect обнаружили проблемы разного уровня опасности — от потенциальных слабых мест до признаков кражи данных.

Это не значит, что 67% интернет-магазинов взломаны. Речь идет о конкретной выборке проверок, которая не представляет весь рынок. Среди всех выявленных проблем 4% относились к категории malicious — с свидетельством кражи карточных данных. Остальные были подозрительными или потенциально опасными.

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

Что помогает снизить риски

Один из практических шагов — организовать оплату так, чтобы магазин не собирал карточные реквизиты своими формами.

К примеру, WayForPay предлагает платежную страницу, на которой покупатель вводит реквизиты, и платежный виджет. Виджет открывается поверх страницы магазина, но, по документации, фактически оплата производится на стороне WayForPay. Это позволяет использовать готовую платежную форму вместо самостоятельной реализации сбора карточных данных.

Ключевое значение имеет правильное соединение. Разработчик должен проверить, что реквизиты не собираются дополнительными полями магазина, не попадают в его журналы или инструменты аналитики, а платежный компонент загружается из официального источника.