web skimming

Web skimming to wstrzyknięcie złośliwego JavaScriptu na stronę zamówienia sklepu internetowego, który w tle przechwytuje dane kart płatniczych wpisywane przez klientów i wysyła je przestępcom. Niebezpiecznik nazywa taki kod webowym skimmerem, czyli kodem podrzucanym na stronę w celu przejmowania danych o kartach kredytowych ^[1]. Zjawisko bywa nazywane e-skimmingiem, a PCI Security Standards Council zauważa, że liczba takich ataków w transakcjach e-commerce znacznie wzrosła ^[4]. Nazwa Magecart oznacza zbiorczo kilka grup przestępczych atakujących sklepy internetowe ^[2].

Jak działa

Skimmer działa w przeglądarce klienta, a nie na serwerze sklepu. Sklep wygląda i działa normalnie, zamówienie zostaje przyjęte, płatność przechodzi. Równolegle skrypt kopiuje zawartość pól formularza i przesyła ją na serwer atakującego. Klient i sprzedawca zwykle dowiadują się o tym dopiero, gdy bank wykryje nadużycia na kartach.

Sucuri opisał w styczniu 2025 roku skimmer z WordPressa, który uruchamiał się tylko wtedy, gdy adres strony zawierał słowo „checkout”, a nie zawierał „cart” ^[3]. Kod albo tworzył fałszywy formularz płatności, udający formularz operatora, albo przechwytywał dane wpisywane w prawdziwe pola w czasie rzeczywistym ^[3]. Dane były kodowane, szyfrowane i wysyłane funkcją navigator.sendBeacon, która nie zakłóca składania zamówienia ^[3].

Przebieg pokazuje schemat poniżej.

RYS. 1Kradzież danych karty przez skimmer

Kod skimmera jest zwykle poddany zaciemnianiu, żeby utrudnić jego rozpoznanie. Sama wysyłka danych na obcy serwer to eksfiltracja danych.

W WordPressie

Sklepy na WooCommerce są celem tak samo jak inne platformy. Skimmer trafia na stronę zwykle przez podatność we wtyczce, przejęte konto administratora albo zmodyfikowany skrypt zewnętrzny. Miejsca, w których bywa ukryty, zestawia tabela.

Przypadek z bazy danych jest pouczający. Sucuri zaznacza, że wstrzyknięcie do bazy zamiast do plików motywu lub wtyczek pozwala uniknąć wykrycia przez popularne narzędzia skanujące pliki ^[3]. Złośliwy kod znaleziono w bloku HTML widżetu, wstawionym przez panel administracyjny w sekcji widżetów ^[3], czyli przez zwykły interfejs WordPressa, bez zmiany żadnego pliku. Dlatego skaner złośliwego oprogramowania, który sprawdza tylko pliki, nie wystarczy; trzeba przeglądać też treść widżetów HTML i opcji w bazie ^[3].

Pokrewne hasło fałszywa bramka płatności opisuje wariant, w którym klient zostaje przekierowany na stronę udającą operatora płatności.

Zagrożenia i skutki

Dla klienta skutkiem jest nieautoryzowane użycie karty. Skradzione numery trafiają na rynek i bywają sprawdzane przez testowanie kart na innych sklepach. Dla sprzedawcy web skimming oznacza naruszenie ochrony danych osobowych klientów, obowiązki wobec organizacji kartowych i utratę zaufania. Skimmer rzadko występuje sam: obecność złośliwego kodu w sklepie oznacza, że atakujący miał dostęp do strony i mógł zostawić tylną furtkę.

Jak się bronić

Wymagania PCI DSS. Standard PCI DSS w wersji 4 zawiera dwa wymagania skierowane przeciw e-skimmingowi: 6.4.3 i 11.6.1 ^[4]. Według Rady PCI ich sens polega na tym, by skrypty strony płatności były autoryzowane, sprawdzane pod kątem integralności i monitorowane pod kątem modyfikacji ^[4]. W marcu 2025 roku Rada opublikowała do nich osobny dokument z wytycznymi ^[4].

Kontrola skryptów w przeglądarce. Content Security Policy pozwala stronie ograniczyć to, co jej kod może robić w przeglądarce ^[6], w tym źródła, z których ładuje skrypty, i adresy, pod które wysyła dane. Subresource Integrity pozwala przeglądarce sprawdzić, czy pobrany plik, na przykład z CDN, nie został zmieniony: strona podaje skrót kryptograficzny, któremu zasób musi odpowiadać ^[5].

<script src="https://cdn.example.com/lib.js"
        integrity="sha384-..." crossorigin="anonymous"></script>

Utwardzenie WordPressa. Dokumentacja WordPressa zaleca aktualizacje wtyczek, usuwanie nieużywanych, instalowanie ich tylko z zaufanych źródeł i uwierzytelnianie dwuetapowe ^[7]. Sucuri dodaje zaporę aplikacyjną i monitorowanie integralności plików ^[3]. Zapora typu WAF utrudnia wykorzystanie znanej podatności, a uwierzytelnianie dwuskładnikowe utrudnia przejęcie konta, przez które skimmer trafia do widżetu.

Historia i przykłady

Magecart, 2020. Sekurak 12 maja 2020 roku opisał ponad 1200 sklepów zainfekowanych skimmerem, w tym kilka polskich domen ^[2]. Schemat polegał na znalezieniu podatności w platformie sklepu i dodaniu kodu, który przy płatności wyświetlał podstawiony formularz ^[2]. Niebezpiecznik, powołując się na analizę badacza Maxa Kerstena, podał liczbę 1236 zainfekowanych stron i zaznaczył, że większość wskazanych polskich sklepów działała na Magento 2 ^[1].

Skimmer w bazie WordPressa, 2025. Opisany wyżej przypadek Sucuri z 9 stycznia 2025 roku pokazuje przesunięcie z plików do bazy danych ^[3].