Нова хвиля Magecart-атак демонструє, наскільки вразливими залишаються e-commerce платформи перед веб supply chain загрозами. Зловмисники навчилися приховувати шкідливий JavaScript безпосередньо у EXIF-метаданих favicon і виконувати його виключно в браузері покупця, не торкаючись коду магазину й не залишаючи слідів у репозиторії.
Magecart через favicon: прихований JavaScript у метаданих EXIF
На скомпрометованих сайтах дослідники виявили мінімалістичний завантажувач — короткий скрипт, який візуально майже не відрізняється від легітимного підключення CDN або платіжного віджета. Такий підхід різко знижує ймовірність виявлення під час ручного або автоматизованого аудиту HTML-коду.
Цей завантажувач довантажує зовнішній скрипт, який за допомогою заплутаних індексів масивів і обфускації формує реальну шкідливу URL-адресу, наприклад //b4dfa5[.]xyz/favicon.ico. Далі браузер завантажує favicon як бінарний об’єкт, скрипт вилучає з нього EXIF-метадані, знаходить заховану рядкову payload зі шкідливим JavaScript і виконує її через new Function().
У результаті весь зловмисний код живе всередині метаданих зображення, не міститься у вихідному HTML/JS сторінки і не фігурує в Git-репозиторії. Більшість сканерів, що не аналізують реальне виконання в браузері, просто не бачать цієї активності.
Фінальний етап ланцюжка — приховане викрадення платіжних даних. Введену інформацію картки перехоплює скрипт та відправляє методом POST на домен, контрольований атакуючими. При цьому код магазину не змінюється, а компрометація відбувається повністю на клієнтській стороні.
Чому статичний аналіз коду не виявляє Magecart-атаки
Класичні засоби статичного аналізу коду (SAST) працюють з тим, що зберігається у репозиторії: вихідні файли, конфігурації, IaC-манифести. Вони ефективні проти вразливостей у власному коді — XSS, SQL-ін’єкцій, проблем авторизації, небезпечної обробки даних тощо.
Однак Magecart належить до категорії веб supply chain атак. Шкідливий JavaScript потрапляє на сторінку через скомпрометовані зовнішні компоненти — платіжні віджети, tag manager-и, пікселі аналітики, CDN-сценарії, динамічно завантажувані зображення. Такий код часто ніколи не зберігається у вашому Git, не проходить code review і, з точки зору SAST-сканера, просто не існує.
У статичного аналізу є принципові обмеження: він не здатний «розпакувати» payload, прихований у бінарному favicon; не бачить доменів, які з’являються лише під час реальної сесії користувача; не може зафіксувати аномальні запити з браузера до зовнішніх endpoint-ів. Це не вада продукту, а обмеження моделі загроз, яку він закриває.
Водночас SAST залишається важливим шаром оборони: він виявляє ризикові конструкції у вашому коді — динамічне підключення сторонніх скриптів, надмірне використання eval/new Function, жорстко прописані підозрілі endpoint-и. Тобто зменшує площу атаки, але не замінює моніторинг того, що реально виконується у браузері.
Веб supply chain-атаки: iframe, пікселі, DOM-скрімінг
Невидимий iframe поверх форми оплати
Поширений сценарій Magecart — підміна інтерфейсу через невидимий iframe. Скомпрометований зовнішній віджет накладає прозорий шар на легітимну форму введення картки й перехоплює кожне натискання клавіші, відправляючи дані на сервер атакуючих. HTML-код сторінки формально не змінюється, а в репозиторії немає жодного рядка шкідливого коду.
Компрометація аналітичних пікселів і скриптів
Практично всі e-commerce сайти використовують пікселі аналітики та ретаргетингу, що завантажуються з зовнішніх CDN. У разі компрометації провайдера або його інфраструктури звичний аналітичний скрипт перетворюється на канал витоку даних. Для застосунку це все той самий «довірений» URL, який роками був у білому списку.
DOM-based скрімінг платіжних і облікових даних
Ще один вектор — скрипти, доставлені через tag manager. Вони динамічно підписуються на події введення у поля логіна чи оплати та збирають дані до відправлення форми. Уся логіка живе в обробниках DOM-подій, що додаються вже під час виконання в браузері, тобто залишаються невидимими для статичних сканерів. Ситуацію ускладнює використання AI-генерованого поліморфного JavaScript, який постійно змінює структуру коду й обходить сигнатурні детектори.
Клієнтський runtime-моніторинг і підхід defense in depth
Для протидії Magecart та подібним загрозам критичним стає клієнтський runtime-моніторинг браузера. Такі рішення відстежують, які саме скрипти виконуються в сесії користувача, які зміни вони вносять у DOM та куди надсилають чутливі дані. По суті, вони відповідають на запитання: «Який код прямо зараз працює в браузерах моїх клієнтів і чи не ексфільтрує він інформацію на сторонні домени?»
Рекомендації OWASP та звіти ENISA щодо суплай-чейн загроз підкреслюють необхідність багаторівневого захисту (defense in depth). Поєднання статичного аналізу коду та керування залежностями з політиками CSP, Subresource Integrity, жорстким реєстром довірених сторонніх скриптів і клієнтським runtime-моніторингом дає змогу отримати реальну видимість на рівні браузера.
Компаніям, що працюють в e-commerce або обробляють платіжні дані, варто вже зараз переглянути архітектуру безпеки фронтенду: мінімізувати неконтрольовані інтеграції, впровадити політики виконання скриптів, розгорнути інструменти моніторингу клієнтської сторони й регулярно тестувати готовність до Magecart-подібних інцидентів. Це суттєво зменшить ризик непомітної крадіжки платіжних даних і допоможе відповідати сучасним вимогам кібербезпеки.
