Страница оплаты редко падает и почти всегда работает. Именно поэтому она так удобна для тихой кражи данных: всё выглядит штатно, заказ оформляется, а часть введённого уходит в сторону. Проблема не в том, что «плохой код существует», а в том, что он исполняется там, где его не ждут, - в браузере клиента, среди десятков легитимных скриптов и интеграций.
В этой статье мы расскажем об охоте на такие вмешательства в веб‑продакшене. Будем разбирать, как выглядит e‑skimming технически, какие следы он оставляет, как строить наблюдаемость вокруг платёжных страниц и как превращать отдельные находки в устойчивую систему контроля.
Как работает e-скимминг
Чтобы понять, почему e‑скимминг так живуч, полезно смотреть на платёжную страницу как на экосистему. Редко бывает так, что на ней исполняются только ваши скрипты. Обычно рядом живут аналитика, антифрод‑интеграции, виджеты поддержки, системы персонализации, трекеры рекламных платформ. Иногда всем этим управляет менеджер тегов: формально это одна строчка на странице, но фактически - механизм доставки нового кода без участия релизного цикла продукта.
Технически e‑скимминг начинается с самого приземлённого: злоумышленнику нужно добиться выполнения своего JavaScript-кода в контексте страницы оплаты или рядом с ней, на этапах корзины и оформления заказа, где готовятся данные. Дальше у него есть несколько устойчивых шаблонов.
Самый прямой - перехват ввода. Скиммер подписывается на события в полях формы, аккуратно собирает значения и отправляет их наружу. В простом варианте это выглядит как слушаю input и складываю в буфер. В более хитром - скиммер ждёт, пока пользователь закончит ввод, учитывает маски и форматирование, понимает структуру конкретной формы и собирает данные так, чтобы они выглядели пригодными для использования.
Второй шаблон - перехват отправки. Скиммер не тратит время на каждый символ, а вмешивается в момент нажатия Оплатить: подменяет обработчик формы, переопределяет функцию отправки, перехватывает объект с данными прямо перед токенизацией или перед отправкой провайдеру. Опасность в том, что скиммер получает данные в уже готовом виде - после валидации, нормалализации и других преобразований интерфейса.
Третий шаблон - подмена формы. Пользователь видит привычный дизайн, но поля, обработчики и адреса отправки меняются. Иногда подмена мягкая: добавляются поля‑двойники или скрытые поля, которые уходят на внешний домен. Иногда подмена грубее: пользователь вводит данные в элементы, созданные вредоносным кодом, а настоящая форма остаётся декоративным фоном.
Где появляется скиммер? Не всегда через прямой взлом вашего приложения. Часто это история про цепочку поставки фронтенда: сторонний скрипт был подменён, доступ к менеджеру тегов утёк, временная интеграция осталась в проде, подрядчик получил лишние права, а процесс контроля изменений не успел за маркетингом и продуктом. Поэтому охота на e‑скимминг почти всегда начинается не с поиска подозрительных строк, а с инвентаря и картины фактического исполнения кода в браузере.
Отдельного внимания заслуживают сценарии с менеджерами тегов, например Google Tag Manager. По сути, это легитимный канал доставки произвольного JavaScript кода на страницу. Если атакующий получает возможность менять контейнер, он получает возможность обновлять скиммер без релиза сайта: менять домены эксфильтрации, условия включения, упаковку кода. Исследования показывают использование GTM как первой стадии заражения с последующей подгрузкой дополнительного кода с доменов атакующего.
Технические индикаторы и логирование
Индикаторы e‑скимминга удобнее группировать по двум плоскостям: исполнение кода и сетевые действия платёжной страницы. Задача охоты - сделать эти плоскости наблюдаемыми, а изменения в них - различимыми.Первый и самый практичный класс индикаторов - сетевые отклонения. Платёжный поток обычно общается с ограниченным и объяснимым набором доменов: ваш домен, CDN, домены платёжного провайдера, антифрод‑сервис, капча, иногда - несколько сервисов аналитики. Когда на платёжной странице появляется новый домен назначения, особенно если туда уходят запросы с телом (POST) или запросы совпадают по времени с вводом данных, это сигнал высокого качества.
Второй класс - изменения в источниках скриптов и цепочках загрузки. Появился новый внешний скрипт, изменился адрес уже известного, появился небольшой загрузчик, который через секунду подтягивает следующий слой, - всё это нужно воспринимать как событие. Многоступенчатость - типичная черта e‑скимминга: первый слой выглядит неопасно, а полезная нагрузка появляется позже и может меняться.
Третий класс - изменения в окружении, которое определяет, что браузер разрешит делать странице. Сюда относятся политики выполнения скриптов и настройки, которые влияют на то, какие источники разрешены и какие операции допустимы в DOM (Document Object Model). На практике атакующий иногда сначала ослабляет ограничения, а затем пользуется этим окном, чтобы внедрить скиммер через уже существующий канал.
Логирование должно помогать отвечать на три вопроса: что исполнялось, когда это появилось и чем это было разрешено. Для продакшена важна не идеальная полнота, а воспроизводимость и точность.
Во‑первых, нужен снимок фактических ресурсов платёжной страницы: список скриптов с источниками и порядок загрузки, включая динамически добавленные. Во‑вторых, нужен профиль сетевых направлений: перечень доменов назначения, методы, типовые размеры и частоты запросов, корреляция по времени с событиями формы. В‑третьих, нужны события изменений: новый скрипт, изменение существующего, изменение контейнера менеджера тегов, изменение политики выполнения.
Если эти данные связаны с релизами и изменениями конфигурации, расследование ускоряется на порядок. Если не связаны, команда начинает спорить, было ли так задумано, а скимминг выигрывает временем.
E-скимминг требует проактивного поиска, а не только реакции на алерты - это классическая задача threat hunting. В статье: "Охота на угрозы: Основа в деталях" показано, как строить гипотезы, где искать следы скрытых угроз и как превратить разрозненные находки в воспроизводимый процесс обнаружения.
Охота на скрипты и домены
Охота на e‑скимминг становится эффективной, когда превращается в цикл: эталон → отклонения → разбор причин → закрепление контроля. Это хорошо ложится на мышление антифрода и DS, потому что по сути это работа с базовой линией поведения и аномалиями.Начать стоит с инвентаризации: что на платёжных страницах считается допустимым. Это не список всех файлов на сайте, а список того, что реально исполняется на конкретных критичных маршрутах. В идеале у каждого внешнего скрипта есть причина существования, владелец и понятный способ изменения.
Следующий слой - карта доменов. Для платёжной страницы допустимые домены назначения и домены источников скриптов должны быть ограниченными и конкретными. Чем шире разрешения, тем проще атакующему спрятаться. В реальном продукте полностью закрыть мир трудно, но у каждого исключения должна быть ответственность: кто попросил, кто проверил, как быстро можно отключить, что будет, если домен начнёт вести себя иначе.
Дальше - причинная цепочка. Если появляется новый домен назначения, вопрос не в том, хороший он или плохой, а в том, какой код его вызвал. Если появляется новый скрипт, вопрос не в том, что в нём написано, а в том, почему он вообще загрузился. Полезный результат расследования - не найденный кусок обфусцированного кода, а источник управления: внешний контейнер, уязвимость, компрометация учётки, подмена в сторонней библиотеке, ошибочный процесс публикации.
Отдельно стоит учитывать архитектуру платежа, потому что скимминг адаптируется под неё.
Если оплата идёт через редирект на страницу провайдера, риск кражи данных карты на вашей стороне обычно меньше, но риск подмены логики до редиректа остаётся: можно заменить адрес перехода, подменить кнопку, вмешаться в параметры, увести пользователя на фальшивую страницу оплаты. Кроме того, атакующий может собирать PII (Personally Identifiable Information) и атрибуты заказа: связку аккаунта, телефона, адреса, корзины - это топливо для последующего мошенничества.
Если оплата встроена через iframe или hosted fields, провайдер закрывает часть поверхности, но окружение страницы остаётся вашим. Скимминг может быть направлен не на номер карты, а на токены, идентификаторы сессий, данные доставки, email и телефон, а также на события и флаги, которые затем используются для обхода антифрода.
Если форма полностью ваша, то поверхность атаки максимальна: скиммер может перехватывать ввод, подменять DOM, вмешиваться в отправку и при этом не ломать конверсию. Здесь особенно важно, чтобы контроль исполнения скриптов и контроль сетевых направлений были строгими, а изменения - наблюдаемыми.
Защита от скимминга начинается раньше платёжной страницы - в процессе доставки фронтенда. В материале: "DevSecOps: как встроить безопасность в процесс CI/CD" описано, как встроить автоматические проверки безопасности в CI/CD, чтобы вредоносный код не попадал в продакшен через легитимные каналы обновления.
Практические рекомендации
В защите от e‑скимминга хорошо работает не одна мера, а связка из управления изменениями, технических ограничений и наблюдаемости. Ниже - практический контур, который можно внедрять поэтапно, не привязываясь к конкретному стеку.Первое - выделить платёжный периметр. Нужно явно определить, какие страницы относятся к оплате и к предоплатному потоку, где вводятся чувствительные данные, где формируются токены, где есть персональные данные. На эти страницы накладываются отдельные правила: изменения только через понятный процесс, минимум интеграций, ясные владельцы.
Второе - привести в порядок внешние интеграции и менеджеры тегов. Если менеджер тегов присутствует на платёжных страницах, он должен восприниматься как способ доставки кода в прод, а значит требует такого же контроля, как релиз: ограниченные права, двухфакторная аутентификация, журналирование изменений, ревью, возможность быстрого отката. Истории про скимминг часто начинаются там, где слишком много людей может публиковать изменения, а границы ответственности размыты.
Третье - ограничить выполнение кода в браузере. Строгая Content Security Policy, где скрипты исполняются только при совпадении хэша, это усложняет внедрение чужого JavaScript кода. Trusted Types (TT) дают дополнительный слой: директива require-trusted-types-for 'script' помогает снизить риск DOM‑инъекций, которые превращаются в исполняемый код, и дисциплинирует опасные места вставки в DOM.
CSP создаёт защитный периметр, но настоящая ценность появляется, когда есть отчёты о нарушениях и понятный процесс их разбора. В руководстве: "Фильтрация мусора и Content Security Policy (CSP) отчеты" разобраны техники фильтрации CSP-отчётов: как отсеивать шум от расширений браузера и ловить настоящие аномалии.
Четвёртое - мониторинг изменений как продуктовый инструмент. Нужен механизм, который регулярно проверяет платёжные страницы и поднимает события по отклонениям: новый скрипт, новый домен назначения, изменение контейнера тегов, изменение политики выполнения. Важно, чтобы эти события были привязаны к понятному процессу: если событие не связано с релизом или согласованным изменением, оно должно уходить в расследование.
Пятое - сценарий реагирования, написанный заранее. Когда появляется подозрение на e‑скимминг, задача не в том, чтобы найти злую строчку, а в том, чтобы быстро получить фактическую картину: что исполнилось в браузере, какие запросы ушли, какой компонент стал источником. Если в цепочке есть менеджер тегов, проверяется контейнер и история публикаций. Если есть сторонний скрипт, проверяется его источник, версия, изменения и причина, по которой он был разрешён.
И отдельный бонус для антифрода и DS: события, которые вы собираете для охоты на скимминг, можно превращать в признаки для риск‑оценки и расследований. Появление нового домена на платёжной странице, новая цепочка загрузки, изменения политик выполнения, всплески запросов в сторону - всё это может коррелировать с волнами мошенничества и утечек, а значит быть частью аналитического контура.
Заключение
E‑скимминг выигрывает там, где платёжная страница воспринимается как обычный экран, а не как зона повышенного контроля. Охота на него начинается с дисциплины: знать, какие скрипты реально исполняются у пользователя, и иметь чёткую картину сетевых направлений в момент ввода и отправки данных.Скиммеры любят серые зоны: внешние интеграции без владельца, менеджеры тегов без строгих прав, широкие разрешения по доменам, изменения без трассировки к релизу. Защита выигрывает там, где есть эталон, контроль изменений, ограничения на выполнение и короткое окно обнаружения. Тогда даже если скиммер появится, он живёт недолго - а это и есть практическая цель охоты.
Вложения
Последнее редактирование:
