Zainfekowany sklep internetowy — skimmer kart, fałszywe bramki płatności i co masz obowiązek zrobić

Infekcja strony wizytówki to problem wizerunkowy i spadek w Google. Infekcja sklepu to problem innego kalibru: przez stronę przechodzą dane klientów, adresy, czasem dane kart. Atakujący o tym wiedzą i dla sklepów mają osobny zestaw narzędzi. Ten wpis jest o tym, czym różni się infekcja sklepu, jak ją rozpoznać i co właściciel sklepu musi zrobić poza samą naprawą.

Czym jest skimmer

Skimmer to fragment kodu, zwykle JavaScript, który na stronie zamówienia czyta to, co klient wpisuje w formularz (numer karty, datę ważności, kod CVV, dane adresowe), i wysyła kopię na serwer atakującego. Klient niczego nie zauważa, płatność przechodzi normalnie. Znane jako ataki typu Magecart, bo zaczęły się od sklepów na Magento, dziś dotyczą każdej platformy: WooCommerce, PrestaShop, OpenCart, Shoper z własnymi modyfikacjami.

Druga odmiana: fałszywa bramka płatności. Skrypt podmienia krok płatności na własny formularz, który wygląda jak bramka (Przelewy24, PayU, Stripe), zbiera dane karty, wyświetla „błąd, spróbuj ponownie” i przekierowuje na prawdziwą bramkę. Klient płaci drugi raz, już naprawdę, i o niczym nie wie.

Dlaczego zwykły skaner tego nie znajdzie

Skimmer to często jedna linia w szablonie albo wpis w bazie, ładujący skrypt z zewnętrznej domeny, która udaje coś legalnego: google-analytlcs.com, jquery-cdn.net, woocommerce-assets.org. Sam skrypt jest zaciemniony i aktywuje się tylko na adresach z /checkout, /zamowienie, /platnosc. Skaner plików PHP nie widzi JavaScriptu ładowanego z zewnątrz. Skaner, który sprawdza stronę główną, nie wchodzi na stronę zamówienia.

Jak sprawdzić sklep

1. Przejdź przez cały proces zamówienia w trybie prywatnym z narzędziami deweloperskimi otwartymi na zakładce Sieć (Network). Zapisz listę domen, z których ładują się skrypty na stronie płatności. Każda, której nie znasz, jest podejrzana.
2. Porównaj z listą, którą znasz. Bramka płatności, analityka, czat, czcionki. Wszystko inne wymaga wyjaśnienia.
3. Przeszukaj szablon i bazę pod kątem <script src= z obcymi domenami i pod kątem fraz checkout, card, cvv, atob(, fromCharCode w plikach JS i w tabelach z ustawieniami.
4. Sprawdź pliki JS motywu i wtyczek pod kątem dat modyfikacji: find . -name "*.js" -mtime -60. Zmieniony jquery.min.js to klasyka.
5. W WooCommerce przejrzyj listę bramek płatności: nieznana bramka albo zmieniony adres powrotu w znanej to sygnał.

Jak naprawić

Standardowa kolejność: kopia, porównanie plików z wydaniem, kwarantanna obcych plików, przegląd bazy, czyszczenie .htaccess, hasła, aktualizacje. Trzy rzeczy specyficzne dla sklepu:

• Zmień klucze API bramek płatności i klucze webhooków. Jeśli atakujący miał dostęp do plików, miał też dostęp do kluczy.
• Sprawdź, czy nie zmieniono numeru konta w ustawieniach płatności przelewem tradycyjnym i w szablonach maili z potwierdzeniem zamówienia.
• Sprawdź konta pracowników w panelu sklepu i konta z dostępem do zamówień.

Czego nie wolno zrobić

Nie kasuj logów. Nie przywracaj kopii zapasowej sprzed tygodnia bez sprawdzenia, czy nie zawiera już skimmera. Nie pisz jeszcze do klientów, że „nic się nie stało”, dopóki nie wiesz, od kiedy skimmer działał.

Obowiązki właściciela sklepu

Tu kończy się technika, a zaczyna prawo. Sklep przetwarza dane osobowe, więc włamanie jest zwykle naruszeniem ochrony danych w rozumieniu RODO.

• Zgłoszenie do Prezesa UODO w ciągu 72 godzin od stwierdzenia naruszenia, chyba że jest mało prawdopodobne, by naruszenie skutkowało ryzykiem dla osób. Wyciek danych kart i adresów takim ryzykiem jest.
• Powiadomienie klientów, jeśli ryzyko jest wysokie, a przy danych kart jest. Klienci muszą wiedzieć, żeby zastrzec karty.
• Powiadomienie operatora płatności. Agenci rozliczeniowi mają własne procedury przy podejrzeniu wycieku danych kart; nieprzekazanie informacji może skutkować konsekwencjami umownymi.
• Dokumentacja incydentu: co, kiedy, jak wykryto, co zrobiono. Nawet jeśli nie zgłaszasz, musisz umieć wykazać, dlaczego.

Terminy biegną od „stwierdzenia naruszenia”, więc decyzję o zgłoszeniu podejmij w pierwszej dobie, nie po naprawie. To nie jest porada prawna; przy wycieku danych kart skonsultuj się z prawnikiem albo inspektorem ochrony danych.

Od kiedy skimmer działał

Pytanie, które zadają klienci, UODO i operator płatności. Odpowiedź jest w datach modyfikacji zainfekowanych plików, w logach dostępu (pierwsze żądanie do skryptu skimmera) i w archiwum internetu, jeśli strona zamówienia była archiwizowana. Dlatego kwarantanna zamiast kasowania: pliki z datami są dowodem.

W CleanOps skan sklepu działa tak samo jak każdej innej strony: pliki PHP i JS są porównywane z wydaniami i oceniane pod kątem doklejonego kodu, a obce pliki trafiają do kwarantanny. Skryptu ładowanego wyłącznie z obcej domeny skan plików nie zobaczy, dlatego po naprawie poproś asystenta AI, żeby pobrał stronę zamówienia i przejrzał jej kod oraz pliki JS motywu w poszukiwaniu adresów, których nie znasz.