Sklep znów się otwiera, produkty są widoczne, a skaner nie pokazuje poprzedniego ostrzeżenia. Czy można już przyjmować zamówienia? Po włamaniu do PrestaShop to za mało, żeby podjąć taką decyzję. Osobnego sprawdzenia wymagają ścieżka płatności, dostępy do systemu i dane, na których pracuje obsługa sklepu.
Ten poradnik dotyczy odbioru naprawy i przygotowania do wznowienia sprzedaży. Nie jest instrukcją samodzielnego kasowania plików ani dowodem, że konkretny sklep jest bezpieczny. Zakres kontroli powinien wynikać z ustaleń osoby prowadzącej analizę incydentu.
Najpierw ogranicz ryzyko dla kupujących
Jeżeli istnieje podejrzenie podmienionej płatności lub wycieku danych, ustal z hostingiem i wykonawcą sposób ograniczenia dostępu do sklepu. Ważne, aby podejrzana ścieżka zakupu nie była dalej używana przez klientów. Sam komunikat o przerwie nie zastępuje technicznego ograniczenia dostępu, jeśli formularz lub inny adres nadal działa.
Nie sprawdzaj podejrzanej płatności prawdziwą kartą i nie proś o to klienta. Zapisz adres, czas zdarzenia, objawy i komunikaty operatora. Analizę wykonuje się w kontrolowanym środowisku, bez obchodzenia ostrzeżeń przeglądarki.
Ustal też, kto odpowiada za kontakt z hostingiem, operatorem płatności oraz za ocenę możliwego naruszenia danych. Naprawa kodu i ocena skutków dla klientów to osobne zadania. Nie zakładaj, że samo usunięcie malware zamyka oba tematy.
Zachowaj materiał do analizy i aktualne zamówienia
Przed zmianami potrzebna jest kopia plików i bazy z chwili wykrycia incydentu, przechowywana poza publicznym katalogiem sklepu. To materiał do diagnozy, a nie automatycznie czysta kopia do przywrócenia. Zabezpiecz również dostępne logi i raport hostingu, zanim zostaną nadpisane zgodnie z jego zasadami retencji.
Odtworzenie starszej bazy może oznaczać utratę późniejszych zamówień, zmian stanów i informacji o klientach. Dlatego przed przywróceniem backupu trzeba ustalić:
- z jakiej daty pochodzi kopia i dlaczego uznano ją za właściwy punkt odtworzenia;
- jakie zamówienia oraz zmiany powstały później;
- jak zachować i uzgodnić te dane po naprawie;
- jak porównać stan zamówień z potwierdzeniami operatora płatności.
Nie przywracaj bazy w ciemno tylko dlatego, że po odtworzeniu strona wygląda poprawnie.
Sprawdź całą ścieżkę płatności, nie tylko stronę główną
PrestaShop w oficjalnym ostrzeżeniu o skimmerze płatności opisuje podmianę przycisków prowadzącą do fałszywego formularza. W opisanym przypadku kod dodano do pliku aktywnego motywu. To przykład incydentu, nie uniwersalna lokalizacja każdej infekcji.
Kontrola po naprawie powinna uwzględniać to, co rzeczywiście otrzymuje kupujący: koszyk, wybór dostawy, formularz zamówienia i przejście do operatora. Wykonawca powinien zweryfikować ładowane zasoby, docelowe adresy oraz konfigurację metod płatności. Zwróć uwagę na nieuzasadnione dodatkowe pola i zmiany danych odbiorcy płatności.
Testy transakcji planuje się po zabezpieczeniu środowiska, przy użyciu oficjalnego trybu testowego operatora tam, gdzie jest dostępny. Pozytywny test funkcjonalny nie jest równoznaczny z pełną kontrolą bezpieczeństwa.
Usuń przyczynę i uporządkuj dostępy
Raport naprawy powinien wskazać, jakie nieautoryzowane zmiany znaleziono, jaki zakres sprawdzono i co wiadomo o sposobie uzyskania dostępu. Jeśli przyczyny nie udało się potwierdzić, trzeba to zaznaczyć zamiast przedstawiać przypuszczenie jako wynik analizy.
Sprawdzenia wymagają wersje PrestaShop, modułów i motywu, ich źródła, dodatkowy kod oraz środowisko hostingowe. Samo zaktualizowanie rdzenia nie wyjaśnia, czy dostęp był możliwy przez inny element. Historyczna analiza ataku opublikowana przez zespół PrestaShop pokazuje również, dlaczego brak jednego znanego wzorca w logach nie wyklucza włamania. Nie należy traktować zaleceń wersyjnych z tego komunikatu z 2022 roku jako aktualnej listy poprawek.
Z wykonawcą ustal przegląd kont administratorów, uprawnień, dostępów hostingowych i kluczy integracji. Niepotrzebne dostępy należy odebrać, a zmianę haseł i unieważnienie sesji przeprowadzić z zaufanego urządzenia, w uzgodnionej kolejności. Trzeba uwzględnić zależne integracje, żeby nie pozostawić starych danych dostępowych w działających połączeniach.
Zasady bezpieczeństwa PrestaShop zalecają osobne konta, ograniczanie niepotrzebnych uprawnień, aktualizacje modułów oraz kontrolę zamówień i płatności. To element utrzymania, nie gwarancja braku kolejnego incydentu.
Zweryfikuj zamówienia i integracje po odtworzeniu
Sklep może wyświetlać produkty, a jednocześnie nie przekazywać poprawnie zamówień do magazynu lub księgowości. Dlatego odbiór naprawy powinien obejmować także pracę zaplecza.
Przygotuj listę scenariuszy do potwierdzenia:
- zgodność kwoty, waluty i statusu płatności między sklepem a operatorem;
- utworzenie zamówienia i poprawne naliczenie dostawy, podatku oraz rabatu;
- aktualizację stanu magazynowego i brak podwójnego przekazania zamówienia;
- potwierdzenia dla klienta i powiadomienia dla obsługi;
- działanie potrzebnych połączeń z ERP, fakturowaniem i kurierami;
- poprawny zakup na telefonie i komputerze, zgodnie z uzgodnionym planem testów.
Przy każdym wyniku zapisz datę, środowisko i osobę sprawdzającą. Oddziel testy na kopii od testów sklepu produkcyjnego. Nie opisuj testu jako wykonanego, jeżeli sprawdzono tylko konfigurację modułu.
Ustal warunki wznowienia sprzedaży i obserwacji
Przed startem poproś o krótkie podsumowanie: potwierdzone ustalenia, wykonane zmiany, wyniki kontroli oraz pozostałe niewiadome. Ustal, kto podejmuje decyzję o uruchomieniu sklepu i kto reaguje na nowy objaw.
Warto mieć uzgodnioną listę warunków: zakończone prace naprawcze, sprawdzona ścieżka płatności, uzgodnione dane zamówień, działające integracje i przygotowana kopia stanu po naprawie. Do tego plan obserwacji logów, nieautoryzowanych zmian, błędów zakupów i statusów płatności. Brak alertu jednego skanera nie zastępuje tych ustaleń.
Jeśli Google wyświetla ostrzeżenie, sprawdź raport problemów dotyczących bezpieczeństwa w GSC. Po usunięciu wskazanych problemów właściwą procedurą jest prośba o sprawdzenie w tym raporcie. Zgłoszenie pojedynczego adresu do indeksowania nie zastępuje weryfikacji bezpieczeństwa.
Jak przygotować zgłoszenie dotyczące sklepu PrestaShop
W pierwszej wiadomości podaj adres sklepu, opis objawów, czas wykrycia i informację, czy sprzedaż została ograniczona. Napisz, kto obsługuje hosting i płatności oraz czy masz raport z wcześniejszego czyszczenia. Nie przesyłaj haseł ani danych klientów.
Prace nad sklepem PrestaShop mogą wymagać osobno diagnozy, naprawy i testów uruchomienia. Najpierw ustalimy zakres oraz to, jakie informacje i dostępy będą potrzebne. Po przywróceniu działania można zaplanować opiekę techniczną i rozwój sklepu.
Opisz problem ze swoim sklepem - zacznijmy od tego, co zostało potwierdzone i czego jeszcze nie sprawdzono.