Malware w PrestaShop: jak szybko usunąć wirusy?

Przekierowania do obcych stron, podejrzany kod w koszyku, spam w wynikach Google albo nieznane konto administratora to sygnały, których nie warto ignorować. Malware w sklepie PrestaShop może przechwytywać dane klientów, modyfikować proces płatności, wysyłać spam i ponownie infekować pliki nawet po pozornie udanym czyszczeniu.

Największym błędem jest kasowanie pierwszego podejrzanego pliku bez ustalenia źródła włamania. Skuteczna reakcja wymaga zachowania dowodów, sprawdzenia plików i bazy danych, usunięcia mechanizmów trwałego dostępu, aktualizacji sklepu oraz bezpiecznego przywrócenia sprzedaży.

W tym poradniku znajdziesz procedurę, którą możesz wykorzystać podczas pierwszej diagnozy incydentu. Dowiesz się też, jak kopie zapasowe, zapora WAF i odpowiednio dobrany hosting PrestaShop pomagają ograniczyć skutki ataku i szybciej przywrócić działanie sklepu.

Czego dowiesz się z tego wpisu?

Pierwsze minuty po wykryciu infekcji

Na początku nie próbuj jeszcze naprawiać sklepu. Najpierw zatrzymaj rozprzestrzenianie się incydentu i zabezpiecz materiał potrzebny do analizy. Każda aktualizacja, ręczna edycja pliku lub czyszczenie pamięci podręcznej może zmienić znaczniki czasu i utrudnić późniejsze odtworzenie przebiegu włamania.

Najważniejsza zasada. Najpierw izolacja i kopia dowodowa, następnie diagnoza, a dopiero później czyszczenie.

Jeżeli podejrzany kod pojawia się w koszyku, formularzu logowania lub na stronie płatności, wyłącz możliwość składania zamówień. W takim scenariuszu istnieje ryzyko działania skimmera, czyli kodu przechwytującego dane wpisywane przez użytkownika. Sam komunikat o pracach technicznych nie wystarczy, jeżeli zainfekowane zasoby nadal są publicznie dostępne.

Najbezpieczniej ograniczyć ruch na poziomie serwera, zapory lub reverse proxy, pozostawiając dostęp wyłącznie dla zaufanych adresów IP. Jeżeli nie masz takich uprawnień, skontaktuj się z administratorem hostingu i poproś o pomoc w izolacji konta.

Zabezpieczenie dowodów i kopii

Przed rozpoczęciem zmian przygotuj osobne kopie:

• wszystkich plików sklepu wraz z ukrytymi plikami, takimi jak .htaccess i .user.ini,
• pełnej bazy danych,
• logów dostępu, błędów PHP, panelu hostingowego i aplikacji PrestaShop,
• konfiguracji serwera, zadań cron i reguł przekierowań,
• listy modułów, pracowników, kluczy Webservice i integracji zewnętrznych,
• ostatniej kopii zapasowej, która prawdopodobnie powstała przed infekcją.

Kopię dowodową przechowuj poza katalogiem publicznym sklepu. Nie zostawiaj archiwum ZIP ani zrzutu bazy w katalogu dostępnym przez przeglądarkę. Pliki mogą zawierać dane klientów, hasła techniczne, klucze API lub fragmenty złośliwego kodu.

Jeżeli napastnik może być nadal aktywny, po wykonaniu kopii zmień najważniejsze dane dostępowe z czystego urządzenia. Zacznij od panelu hostingowego, kont SSH lub SFTP, głównej skrzynki e-mail oraz konta administratora sklepu. Pełną rotację wszystkich kluczy wykonasz po ustaleniu zakresu incydentu.

Czego nie robić na początku

• Nie aktualizuj PrestaShop w ciemno na działającej, zainfekowanej instalacji.
• Nie usuwaj pliku tylko dlatego, że zawiera funkcję base64_decode lub eval. Takie funkcje bywają używane także przez legalne oprogramowanie.
• Nie przywracaj od razu najnowszego backupu. Kopia mogła już zawierać backdoor.
• Nie przesyłaj całej bazy klientów do publicznego skanera plików.
• Nie loguj się do panelu z komputera, na którym mogło dojść do kradzieży haseł.
• Nie kasuj logów. Mogą wskazać pierwsze żądanie wykorzystujące lukę.

Zapora WAF może blokować część podejrzanych żądań i pomóc w ograniczeniu aktywnego ataku. Nie usuwa jednak kodu, który już trafił do plików, bazy danych lub harmonogramu zadań.

Jak potwierdzić infekcję i ustalić jej zakres

Pojedynczy błąd 500, biała strona albo nagły spadek wydajności nie muszą oznaczać włamania. Mogą wynikać z uszkodzonego modułu, problemu z pamięcią PHP lub nieudanej aktualizacji. Diagnoza powinna połączyć obserwację sklepu, analizę logów oraz kontrolę plików i bazy.

Sygnały, które powinny wzbudzić alarm

• Przekierowanie do obcej domeny pojawia się tylko na urządzeniu mobilnym lub po wejściu z Google.
• W kodzie koszyka albo płatności są ładowane nieznane skrypty JavaScript.
• W wynikach wyszukiwania pojawiają się podstrony ze spamem, lekami, kasynami lub fałszywymi produktami.
• Google Search Console albo przeglądarka pokazuje ostrzeżenie o szkodliwej witrynie.
• W panelu znajduje się pracownik, klucz API lub moduł, którego nikt z zespołu nie utworzył.
• Zadanie cron uruchamia plik o losowej nazwie albo pobiera kod z obcej domeny.
• W katalogach na zdjęcia i załączniki pojawiają się pliki PHP.
• Serwer wysyła dużą liczbę wiadomości albo łączy się z nieznanymi adresami.
• Pliki index.php, .htaccess, kontrolery lub szablony zmieniają się bez wdrożenia.
• Po usunięciu złośliwego pliku infekcja powraca po kilku godzinach.

Jeżeli sklep wyświetla białą stronę, najpierw sprawdź logi i źródło błędu. Pomocne procedury znajdziesz w poradniku jak diagnozować białą stronę w PrestaShop. Tryb debugowania włączaj tylko na czas analizy i nie pozostawiaj go aktywnego w publicznie dostępnym sklepie, ponieważ może ujawniać ścieżki, konfigurację i szczegóły błędów.

Sprawdzanie bez otwierania zainfekowanej strony

Malware może stosować cloaking i pokazywać inną treść administratorowi, robotowi Google, użytkownikowi mobilnemu albo osobie wchodzącej z reklamy. Zamiast wielokrotnie otwierać podejrzany adres w zwykłej przeglądarce, pobierz odpowiedź w izolowanym środowisku za pomocą narzędzia curl.

curl -sS -L -D headers.txt -o response.html https://sklep.example/
curl -sS -L -A "Googlebot" -o response-googlebot.html https://sklep.example/
diff -u response.html response-googlebot.html

Porównaj przekierowania, nagłówki, zewnętrzne skrypty i zawartość obu odpowiedzi. Adres przykładowy zastąp domeną sklepu. Nie uruchamiaj pobranego kodu na komputerze używanym do codziennej pracy.

W raporcie Problemy dotyczące bezpieczeństwa w Google Search Console sprawdź typ wykrytego zagrożenia i przykładowe adresy. Pamiętaj, że lista przykładowych URL-i może być niepełna. Musisz przeanalizować cały serwis, a nie tylko strony wskazane przez Google.

Sprawdzenie kont, integracji i logów

W panelu PrestaShop przejrzyj pracowników, ich role, daty ostatnich logowań oraz zakres uprawnień. Następnie sprawdź klucze Webservice, integracje płatnicze, połączenia z systemem ERP, narzędzia marketingowe i moduły wysyłkowe. Każdy nieznany klucz potraktuj jako potencjalny kanał ponownego dostępu.

W logach szukaj przede wszystkim:

• serii żądań POST do plików modułów lub kontrolerów,
• nietypowych parametrów zawierających fragmenty SQL, zakodowane dane lub długie ciągi znaków,
• przesyłania plików poza standardowym panelem administracyjnym,
• żądań do nieznanych plików PHP o krótkich albo losowych nazwach,
• logowań z nowych adresów IP i nietypowych krajów,
• zmiany zachowania aplikacji bez odpowiadającego jej wdrożenia.

Zbuduj prostą oś czasu. Połącz najstarszy podejrzany wpis w logu, czas modyfikacji plików, powstanie nieznanego konta i pierwsze zgłoszenie klienta. Dzięki temu łatwiej ustalisz, jak daleko trzeba cofnąć się podczas wyboru czystej kopii.

Gdzie szukać malware w plikach i bazie danych

Infekcja PrestaShop rzadko ogranicza się do jednego pliku. Napastnik może dodać backdoor w module, zmienić szablon płatności, umieścić web shell w katalogu na załączniki, dopisać przekierowanie w .htaccess albo zapisać złośliwy JavaScript bezpośrednio w bazie danych.

Pliki i katalogi podwyższonego ryzyka

W pierwszej kolejności sprawdź katalog główny, moduły, aktywny motyw, nadpisania w override, katalog administracyjny, zadania cron oraz miejsca, do których aplikacja może zapisywać dane. Szczególnej uwagi wymagają katalogi na zdjęcia, importy, eksporty, załączniki, pliki do pobrania i pamięć podręczną.

Poniższe polecenia mogą pomóc znaleźć ostatnio zmieniane pliki, skrypty PHP w katalogach zapisywalnych oraz często spotykane konstrukcje. Uruchamiaj je na kopii sklepu albo w trybie tylko do odczytu.

find . -type f -mtime -14 -print

find img upload download var -type f \
  \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \) -print

grep -RInE --include="*.php" \
  'eval[[:space:]]*\(|base64_decode[[:space:]]*\(|gzinflate[[:space:]]*\(|shell_exec[[:space:]]*\(|passthru[[:space:]]*\(' \
  modules themes override img upload download

Wynik skanowania jest listą tropów, a nie gotową listą malware. Legalny moduł może korzystać z kodowania lub kompresji, a dobrze ukryty backdoor może nie zawierać żadnej z tych funkcji. Oceniaj kontekst, pochodzenie pliku, datę modyfikacji i zgodność z oryginalnym pakietem.

Skuteczna jest również kontrola integralności. Pobierz czystą paczkę tej samej wersji PrestaShop oraz oryginalne pakiety modułów i motywu. Porównaj je z kopią środowiska produkcyjnego. Nie zastępuj automatycznie plików konfiguracyjnych, zdjęć produktów ani materiałów klientów.

Zwróć uwagę na:

• pliki PHP umieszczone w katalogach, które zwykle przechowują wyłącznie obrazy lub dokumenty,
• krótkie pliki z jednym długim, zakodowanym ciągiem znaków,
• pliki podobne nazwą do legalnych plików, ale z literówką lub dodatkowym rozszerzeniem,
• kod dołączający skrypty z domen niezwiązanych ze sklepem,
• reguły przekierowań zależne od urządzenia, referera albo user-agenta,
• pliki utworzone w kilku katalogach w tej samej sekundzie,
• zmiany w szablonach koszyka, logowania i płatności,
• pliki wykonywalne należące do niewłaściwego użytkownika systemowego.

Baza danych też może przechowywać złośliwy kod

Nie zakładaj, że usunięcie zmienionych plików kończy incydent. Oficjalny zespół PrestaShop opisywał falę ataków SQL Injection, w których złośliwy JavaScript był zapisywany w bazie. Jednym z analizowanych miejsc była wartość konfiguracji PS_SHOP_NAME. To dobry przykład pokazujący, dlaczego skanowanie samego systemu plików nie wystarcza.

Najpierw sprawdź prefiks tabel zapisany w konfiguracji sklepu. Nie zakładaj automatycznie, że jest to ps_. Następnie wykonaj zrzut bazy i przeszukaj go jako tekst.

mysqldump --single-transaction --routines --triggers NAZWA_BAZY > incident.sql

grep -Ein \
  '<script|<iframe|javascript:|fromCharCode|atob\(|base64' \
  incident.sql

Warto również wykonać zapytanie tylko do odczytu w tabeli konfiguracji. Zastąp PREFIX_ rzeczywistym prefiksem swojej instalacji.

SELECT name, value
FROM PREFIX_configuration
WHERE value LIKE '%<script%'
   OR value LIKE '%<iframe%'
   OR value LIKE '%javascript:%'
   OR value LIKE '%base64%';

Rozszerz kontrolę na opisy produktów, strony CMS, kategorie, ustawienia motywu, treść bloków, niestandardowe tabele modułów i dane przechowywane przez integracje. Szukaj nie tylko tagów script, ale też nieznanych domen, kodowania znaków, ukrytych ramek, zdarzeń JavaScript oraz fragmentów odtwarzających kod dopiero w przeglądarce.

Warto wiedzieć. Nie edytuj produkcyjnej bazy metodą prób i błędów. Najpierw wykonaj kopię, pracuj na klonie i zapisuj każde usunięte pole oraz rekord.

Oficjalne omówienie opisanego ataku znajdziesz w komunikacie SQL Injection attacks alert and security enhancements for PrestaShop.

Jak skutecznie wyczyścić sklep bez utraty zamówień

Czyszczenie powinno odbywać się na odizolowanej kopii. Środowisko robocze nie może wysyłać wiadomości do klientów, wykonywać prawdziwych płatności ani uruchamiać integracji magazynowych. Wyłącz wychodzącą pocztę, produkcyjne webhooki i automatyczne zadania, które mogłyby zmienić dane w zewnętrznych systemach.

Najpewniejszą metodą nie jest ręczne poprawianie każdego podejrzanego pliku, lecz odbudowanie aplikacji z zaufanych źródeł. W nowym katalogu przygotuj czysty rdzeń PrestaShop, ponownie zainstaluj potrzebne moduły z oryginalnych paczek i dodaj sprawdzony motyw. Materiały ze starej instalacji przenoś selektywnie po ich przeskanowaniu.

Co usunąć, a co odtworzyć

• Rdzeń PrestaShop. Zastąp plikami pochodzącymi z oficjalnej paczki zgodnej z wybraną ścieżką aktualizacji.
• Moduły. Usuń ich stare katalogi i wgraj ponownie zweryfikowane wydania producentów. Samo nadpisanie może pozostawić dodatkowy backdoor.
• Motyw. Porównaj z oryginałem. Sprawdź szczególnie pliki koszyka, konta klienta, strony zamówienia i szablony wiadomości.
• Override. Zweryfikuj każdy plik ręcznie. Jeżeli nie wiesz, do czego służy, ustal jego autora i powiązany moduł.
• Zdjęcia i dokumenty. Przenoś tylko dozwolone formaty. Sprawdź podwójne rozszerzenia i pliki wykonywalne.
• Baza danych. Usuń potwierdzone wstrzyknięcia, nieznane konta, klucze, cron i konfiguracje dodane przez napastnika.
• Pamięć podręczna. Wyczyść ją dopiero po usunięciu źródła infekcji, aby nie utracić śladów zbyt wcześnie.

Usuń nieużywane moduły również z serwera. Samo wyłączenie ich w panelu nie oznacza, że podatny plik PHP przestaje być dostępny przez internet. Dotyczy to zwłaszcza starych integracji, testowych importów, generatorów plików i dodatków instalowanych tylko na czas kampanii.

Strategia odtwarzania danych

Decyzja o przywróceniu backupu zależy od daty infekcji i liczby zamówień złożonych później. Najnowsza kopia nie zawsze jest najbezpieczniejsza, a najstarsza czysta kopia może nie zawierać aktualnych klientów, płatności i stanów magazynowych.

W poradniku o zasadzie backupu 4×4 znajdziesz rozwinięcie dobrych praktyk tworzenia wielu kopii i przechowywania ich w różnych lokalizacjach. W przypadku sklepu internetowego równie ważne jest regularne testowanie odtwarzania. Backup, którego nigdy nie udało się przywrócić, pozostaje tylko założeniem.

PrestaShop zaleca wykonanie kopii zarówno plików, jak i bazy danych. Dokumentacja przypomina również, aby nie przechowywać archiwów w publicznym katalogu sklepu. Szczegóły znajdziesz w oficjalnym poradniku tworzenia kopii zapasowej PrestaShop.

Jak zamknąć lukę i odciąć ponowny dostęp

Usunięcie malware bez znalezienia punktu wejścia daje tylko chwilowy efekt. Przyczyną może być podatny moduł, nieaktualny rdzeń, skradzione hasło, zbyt szerokie uprawnienia, pozostawiony skrypt importujący albo przejęty komputer administratora.

Aktualizacja PrestaShop i modułów

W dniu publikacji tego wpisu (20 lipca 2026 roku) najnowszymi znalezionymi wydaniami utrzymaniowymi były PrestaShop 9.1.4 oraz 8.2.7. Przed wdrożeniem zawsze ponownie sprawdź stronę projektu, ponieważ wersje i poprawki bezpieczeństwa mogą zmienić się już po publikacji tego artykułu.

Szczególnie ważny jest moduł wyszukiwania fasetowego. Oficjalny komunikat bezpieczeństwa wskazuje, że wersje ps_facetedsearch od 3.0.0 do 4.0.3 mogły w określonych warunkach pozwolić na nieautoryzowane wykonanie kodu. Poprawkę wprowadzono w wersji 4.0.4. Sprawdź aktualną wersję modułu nawet wtedy, gdy wydaje Ci się, że sklep nie korzysta aktywnie z filtrów.

Aktualne informacje znajdziesz w komunikatach PrestaShop 9.1.4 i 8.2.7 oraz aktualizacja bezpieczeństwa Faceted Search.

Dziurawe moduły PrestaShop

Faceted Search nie jest jedynym dodatkiem, w którym wykryto groźną lukę. W ostatnich komunikatach bezpieczeństwa pojawiały się także moduły narażone na SQL Injection, przejęcie konta klienta lub wykonanie kodu zapisanego w bazie. Nie każda z tych podatności prowadzi bezpośrednio do instalacji malware, ale może otworzyć napastnikowi drogę do danych sklepu, panelu administracyjnego albo trwałej modyfikacji witryny. Warto sprawdzić między innymi:

• Contact Information (ps_contactinfo) – wersje do 3.3.2 włącznie były podatne na warunkowy stored XSS, który mógł zostać wykorzystany po wcześniejszym wstrzyknięciu złośliwej treści do bazy przez inny podatny moduł. Problem usunięto w wersji 3.3.3. Szczegóły opisuje komunikat GHSA-35pq-7pv2-2rfw.
• PrestaShop Checkout (ps_checkout) – podatność umożliwiająca przejęcie konta klienta dotyczyła wersji od 1.3.0 do 4.4.0 oraz od 5.0.0 do 5.0.4. Poprawki wydano w wersjach 4.4.1 i 5.0.5, zależnie od używanej linii modułu. Więcej informacji znajdziesz w advisory CVE-2025-61922.
• Advanced Popup Creator (advancedpopupcreator) – wszystkie wersje starsze niż 1.2.7 uznano za podatne na nieuwierzytelniony SQL Injection. Luka pozwalała zdalnie wykonywać zapytania do bazy, a jej wykorzystanie zaobserwowano podczas analiz incydentów. Problem załatano w wersji 1.2.7. Szczegóły zawiera komunikat CVE-2025-69633.
• Monetico Paiement (MoneticoPaiement) – wersje do 1.1.0 włącznie zawierały kilka parametrów umożliwiających nieuwierzytelniony SQL Injection. Poprawkę opublikowano w wersji 1.1.1. Zakres podatności opisano w advisory CVE-2023-45256.

Jeżeli którykolwiek z tych modułów był zainstalowany w podatnej wersji, sama aktualizacja może nie wystarczyć. Sprawdź logi, konta pracowników, klucze Webservice, zadania cron, zmiany w plikach i zawartość bazy danych. Przy luce umożliwiającej SQL Injection albo przejęcie konta warto również zmienić hasła i tokeny integracji, ponieważ napastnik mógł wykorzystać podatność jeszcze przed instalacją poprawki. Nieaktywne, ale nadal obecne na serwerze moduły usuń, zamiast pozostawiać je wyłącznie wyłączone w panelu.

Aktualizację przeprowadź najpierw na kopii sklepu. Wykonaj pełny backup, sprawdź zgodność motywu i modułów, a następnie przetestuj proces przez oficjalny Update Assistant. Procedurę opisuje dokumentacja aktualizacji PrestaShop.

Pełna rotacja danych dostępowych

Zmiana hasła jednego administratora nie wystarczy. Napastnik mógł skopiować klucz API, utworzyć własne konto lub pozyskać dostęp do skrzynki służącej do resetowania haseł. Rotację wykonuj z czystego urządzenia i w zaplanowanej kolejności.

• panel klienta i panel hostingowy,
• SSH, SFTP, FTP i konta wdrożeniowe,
• wszyscy pracownicy PrestaShop,
• główne skrzynki e-mail i konta odzyskiwania,
• hasło użytkownika bazy danych,
• klucze Webservice i tokeny integracji,
• SMTP oraz systemy do wysyłki newsletterów,
• operator płatności, system kurierski i ERP,
• CDN, DNS, rejestrator domeny i reverse proxy,
• repozytorium kodu i automatyczne wdrożenia,
• narzędzia analityczne, reklamowe i tag manager.

Po zmianie danych unieważnij aktywne sesje oraz stare tokeny. Włącz uwierzytelnianie dwuskładnikowe wszędzie, gdzie jest dostępne. Zasady tworzenia i przechowywania danych logowania rozwija poradnik jak tworzyć dobre hasła.

Uprawnienia i mechanizmy ochronne

Sprawdź właścicieli plików i katalogów. Często stosowanym punktem wyjścia są uprawnienia 755 dla katalogów oraz 644 dla plików, ale ostateczne wartości zależą od konfiguracji PHP i serwera. Nie rozwiązuj problemów przez ustawienie 777 dla całej instalacji.

Instrukcję diagnozowania właścicieli oraz praw zapisu znajdziesz w artykule o naprawie uprawnień w PrestaShop.

Po incydencie warto również:

• zablokować wykonywanie PHP w katalogach przeznaczonych na obrazy i dokumenty, jeżeli pozwala na to architektura serwera,
• ograniczyć dostęp do panelu administracyjnego przez VPN lub listę dozwolonych adresów IP,
• usunąć nieużywane moduły, konta, klucze i zadania cron,
• włączyć WAF oraz reguły chroniące przed SQL Injection, XSS i próbami siłowymi,
• ustawić alerty na powstanie nowego pracownika i zmianę krytycznych plików,
• monitorować połączenia wychodzące serwera,
• przechowywać kopie poza kontem hostingowym i okresowo testować odtwarzanie,
• ograniczyć każdemu pracownikowi uprawnienia do faktycznie potrzebnych funkcji.

Dobra praktyka. Zmiana adresu katalogu administracyjnego może ograniczyć automatyczny ruch, ale nie zastępuje aktualizacji, silnego uwierzytelniania i kontroli dostępu.

Bezpieczne przywrócenie sprzedaży

Sklep można ponownie otworzyć dopiero wtedy, gdy usuniesz złośliwy kod, zamkniesz wykorzystaną lukę i zakończysz rotację dostępów. Przed publikacją przeprowadź testy na odizolowanym środowisku, a następnie wykonaj końcową kontrolę po wdrożeniu.

Testy przed ponownym uruchomieniem

• Załóż testowe konto klienta i sprawdź logowanie oraz odzyskiwanie hasła.
• Dodaj kilka różnych produktów do koszyka, zastosuj kupon i zmień dostawę.
• Złóż zamówienie w trybie testowym operatora płatności.
• Sprawdź status płatności, potwierdzenia, fakturę, e-maile i zmianę stanu magazynowego.
• Przetestuj zwrot, anulowanie i ponowne wysłanie wiadomości.
• Zweryfikuj integracje kurierskie, ERP, marketplace, webhooki i API.
• Uruchom ręcznie kontrolowane zadania cron i sprawdź ich logi.
• Sprawdź wersję mobilną, różne przeglądarki, wersje językowe oraz multistore.
• Otwórz narzędzia deweloperskie przeglądarki i przejrzyj domeny w zakładce Network.
• Przeskanuj ponownie pliki, bazę i listę kont po zakończeniu testów.

W zakładce Network nie powinny pojawiać się nieznane skrypty, piksele ani żądania wysyłane podczas wpisywania danych klienta. Każdą nową domenę porównaj z listą używanych integracji. Nie zakładaj, że plik o nazwie przypominającej bibliotekę analityczną jest legalny.

Usunięcie ostrzeżeń Google

Po wyczyszczeniu wszystkich problemów przejdź do raportu bezpieczeństwa w Google Search Console. Przetestuj poprawione strony i poproś o weryfikację. W opisie zgłoszenia wskaż:

• jaki problem został wykryty,
• jak usunięto złośliwy kod,
• jak zamknięto źródło włamania,
• jakie aktualizacje i zmiany dostępów wykonano,
• w jaki sposób potwierdzono, że problem nie występuje w innych częściach serwisu.

Nie wysyłaj prośby o weryfikację po usunięciu tylko jednego przykładowego URL-a. Google oczekuje naprawienia problemu w całej witrynie. Proces może potrwać, dlatego równolegle monitoruj raport, indeksowanie i ruch organiczny.

Monitorowanie po incydencie

Przez pierwsze dni po ponownym otwarciu sklepu zwracaj szczególną uwagę na nowe pliki, zmiany kont, nietypowe żądania i połączenia wychodzące. Powrót tego samego pliku lub kodu zwykle oznacza, że pozostawiono mechanizm trwałego dostępu albo nie usunięto pierwotnej luki.

• Porównuj sumy kontrolne krytycznych plików.
• Ustaw alert na pliki PHP powstające w katalogach zapisywalnych.
• Śledź próby logowania do panelu i konta hostingowego.
• Monitoruj zmiany w cron, kluczach Webservice i pracownikach.
• Przeglądaj błędy aplikacji oraz nagłe wzrosty użycia procesora i poczty.
• Obserwuj skargi klientów, nieoczekiwane przekierowania i porzucone płatności.

Jeżeli analiza wskazuje możliwość przejęcia danych osobowych lub płatniczych, udokumentuj zakres incydentu i skonsultuj dalsze działania z osobą odpowiedzialną za bezpieczeństwo, ochronę danych oraz obsługę prawną. Nie ograniczaj oceny skutków do samego przywrócenia strony.

Odpowiednia infrastruktura nie zastąpi aktualizacji i procedury reagowania na incydenty, ale może znacząco ułatwić ochronę oraz odtwarzanie sklepu. W ofercie hostingu PrestaShop w cyber_Folks znajdziesz między innymi wielowarstwową ochronę WAF oraz kopie zamówień wykonywane co 6 godzin i dostępne do 28 dni wstecz. To przydatne zabezpieczenia zarówno podczas codziennej pracy, jak i po wykryciu incydentu.