На практике массовые сканеры репозиториев бессильны перед атаками, которые никогда не затрагивают ваш код. Недавняя Magecart-кампания наглядно это демонстрирует: полезная нагрузка была спрятана в EXIF-метаданных динамически подгружаемого favicon, а весь вредоносный JavaScript исполнялся исключительно в браузере покупателя на этапе оформления заказа.
Как работает новая Magecart-атака через favicon и EXIF-метаданные
Исследователи зафиксировали на скомпрометированных сайтах короткий загрузчик — небольшой скрипт, который визуально напоминает обычное подключение стороннего ресурса. На первый взгляд он выглядит как безобидный инклюд из легитимного CDN-провайдера (например, Shopify), что резко снижает вероятность его выявления при обратном анализе страницы.
Загрузчик подтягивает внешний скрипт, который затем с помощью запутанных индексов массивов конструирует реальный вредоносный URL. После декодирования он указывает на ресурс вида //b4dfa5[.]xyz/favicon.ico. С этого момента начинается наиболее интересная часть техники: скрипт получает favicon как бинарный объект, извлекает из него EXIF-метаданные, выделяет спрятанную строку с JavaScript-кодом и выполняет её через new Function(). Таким образом, полезная нагрузка живёт внутри метаданных изображения и не видна инструментам, которые не наблюдают фактическое исполнение кода в браузере.
Финальный этап цепочки — скрытая отправка похищенных данных платежных карт методом POST на сервер, контролируемый злоумышленниками. Вся цепочка характеризуется четырьмя ключевыми свойствами: исходный загрузчик маскируется под легитимный сторонний скрипт;_payload_ спрятан в бинарных EXIF-данных favicon; эксфильтрация идёт напрямую из браузера покупателя; код магазина при этом вообще не модифицируется.
Почему статический анализ кода не видит такие атаки
Инструменты класса статического анализа кода, такие как Claude Code Security, по своей природе работают с тем, что есть в репозитории: исходный код приложений, инфраструктурные манифесты, конфигурации. Они прекрасно выявляют уязвимости в первом лице — в том, что разработали и задеплоили вы сами: XSS, SQL‑инъекции, небезопасные обработки данных, ошибки авторизации и т.д.
Однако Magecart‑атаки относятся к веб supply chain угрозам. Вредоносный JavaScript попадает на страницы через скомпрометированные сторонние компоненты: виджеты оплаты, системы тег-менеджмента, аналитические счётчики, CDN‑скрипты и изображения, подгружаемые на лету. Такой код зачастую никогда не попадает в ваш Git‑репозиторий и не проходит code review. Для репозиторного сканера он попросту не существует.
Отсюда естественные ограничения: статический анализ не может интерпретировать полезную нагрузку, спрятанную в бинарном favicon; не видит домены, которые появляются только во время реального сеанса в браузере; не способен детектировать аномальные сетевые запросы на стороне клиента. Это не ошибка продукта, а несовпадение области применения инструмента и класса угроз.
Тем не менее статический анализ остаётся важным слоем защиты. Он может отметить как рискованные собственные конструкции, которые облегчают жизнь злоумышленнику: динамическую вставку сторонних скриптов, избыточное использование eval/new Function, жестко прописанные подозрительные endpoints для отправки данных. То есть он сокращает атакующую поверхность, но не подменяет собой мониторинг того, что реально происходит в браузере пользователя.
Веб supply chain-атаки: не только favicon и EXIF
Злоумышленный iframe поверх формы оплаты
Один из типичных сценариев Magecart‑подобных атак — подмена части интерфейса через iframe. Компрометированный сторонний виджет рисует невидимый оверлей поверх легитимной формы ввода карты и отсылает на сервер атакующего каждое нажатие клавиши. HTML‑разметка магазина формально не меняется, а в репозитории нет ни строки вредоносного кода.
Злоупотребление пикселями и аналитическими скриптами
Практически каждый e‑commerce‑сайт использует пиксели аналитики и ретаргетинга, подгружаемые из внешних CDN. При компрометации поставщика или его инфраструктуры тот же самый пиксель превращается в канал утечки. Для приложения это всё тот же «легитимный» URL, который вызывался годами, а вредоносная логика живёт на стороне третьей партии.
DOM-based кража учётных данных и платежных данных
Ещё один распространённый вектор — скрипты, доставляемые через tag manager. Они динамически подписываются на события ввода в поля логина или оплаты и собирают данные до отправки формы. Вся логика реализована в обработчиках событий DOM, которые добавляются уже при исполнении в браузере, то есть остаются за пределами видимости статических сканеров.
Современные злоумышленники усиливают эти техники за счёт AI‑генерируемого полиморфного JavaScript, регулярно меняя структуру кода и обходя сигнатурные средства контроля. Это ещё сильнее повышает ценность мониторинга реального поведения кода, а не только его текстового представления.
Зачем нужен клиентский runtime-мониторинг и подход defense‑in‑depth
Для класса угроз вроде Magecart ключевым средством контроля становится клиентский runtime‑мониторинг браузера. Такие платформы фиксируют, какие скрипты фактически исполняются в сессии пользователя, какие DOM‑изменения они вносят и куда утекают данные. По сути, они отвечают на вопросы: «Какой код прямо сейчас работает в браузерах моих клиентов?» и «Не пытается ли он отправить чувствительную информацию на посторонние домены?»
Отраслевые рекомендации (например, OWASP и отчёты ENISA по угрозам для supply chain) подчёркивают необходимость многоуровневой защиты. Статический анализ (Claude Code Security и аналоги) и управление зависимостями уменьшают риск внедрения уязвимостей в собственный код. Политики вроде CSP, Subresource Integrity и строгий реестр доверенных сторонних скриптов ограничивают возможности злоумышленника. А клиентский runtime‑мониторинг обнаруживает те атаки, которые реализуются исключительно в браузере и никогда не касаются вашего репозитория.
Оценивать репозиторный сканер по его способности ловить Magecart‑цепочки во favicon — всё равно что ожидать, что дымовой датчик потушит пожар. Это разные категории инструментов, каждая из которых критична на своём уровне. Для надёжной защиты веб‑приложений, особенно в e‑commerce, организациям стоит объединять статический анализ кода, жёсткое управление веб‑supply chain и клиентский runtime‑мониторинг браузера. Такой комплексный подход даёт реальное окно видимости туда, где сегодня живут Magecart и другие формы клиентского скримминга, и существенно снижает риск незаметной кражи платежных данных.
