Bezpieczeństwo PrestaShop i objawy infekcji

Sklep PrestaShop przechowuje dane klientów i zamówień, więc jest atrakcyjnym celem ataków, a większość z nich wykorzystuje znane, łatwe do zamknięcia luki: Nieaktualne moduły, słabe hasła i dodatki z niepewnych źródeł. Ten poradnik zbiera zabezpieczenia, które realnie ograniczają ryzyko, i pokazuje, jak rozpoznać typowy objaw infekcji: Błędy 404 na miniaturkach produktów po nadpisaniu pliku .htaccess. Samo uruchomienie sklepu opisujemy w artykule o PrestaShop na hostingu.

Skąd biorą się włamania na PrestaShop

Automatyczne ataki skanują internet w poszukiwaniu sklepów z lukami, a nie konkretnie Twojego. Najczęściej trafiają w jeden z trzech punktów:

• Nieaktualny PrestaShop lub moduły ze znaną podatnością,
• Słabe hasło do panelu administracyjnego łamane metodą prób,
• Moduły i motywy z niepewnych źródeł, często z ukrytym kodem.

Kolejne sekcje zamykają te furtki po kolei.

Aktualizuj PrestaShop i moduły

To najważniejsze i najtańsze zabezpieczenie. Twórcy łatają luki w aktualizacjach, więc nieaktualny moduł to znana dziura, którą boty potrafią wykorzystać.

• Instaluj aktualizacje rdzenia PrestaShop oraz modułów, gdy tylko się pojawią.
• Usuwaj moduły i motywy, których nie używasz. Nieaktywny dodatek nadal leży na serwerze i nadal może mieć lukę.

Zabezpiecz panel administracyjny

Panel zarządza zamówieniami i danymi klientów, więc to najcenniejszy cel.

• Korzystasz już z firewalla webh. Przed sklepem działa firewall hostingu, który blokuje znaczną część automatycznych ataków, a dostęp do panelu administracyjnego dopuszcza domyślnie tylko z Polski. Jak dostosować te reguły, opisujemy w artykule o firewallu hostingu.
• Zapamiętaj losową nazwę katalogu admina. PrestaShop po instalacji zmienia nazwę folderu admin na losową. Pod tym adresem się logujesz, więc zapisz go w bezpiecznym miejscu i nie zmieniaj na łatwą do odgadnięcia.
• Ustaw silne, unikalne hasło do panelu i każdej osobie nadawaj własne konto z minimalnymi potrzebnymi uprawnieniami.
• Ogranicz dostęp do panelu. Dodatkową warstwą jest hasło na katalog logowania po stronie serwera, opisane w zabezpieczaniu katalogu hasłem.

Usuń pliki instalacyjne

Po instalacji usuń katalog install z serwera. Dopóki istnieje, instalator pozostaje dostępny, co jest realnym ryzykiem. To samo dotyczy pozostawionych plików testowych i kopii konfiguracji.

Instaluj moduły tylko z zaufanych źródeł

Każdy moduł to cudzy kod uruchamiany w Twoim sklepie. Pobieraj dodatki wyłącznie z oficjalnego marketplace PrestaShop lub od sprawdzonych producentów.

Wymuś HTTPS i ważny certyfikat

Sklep przetwarza dane klientów i płatności, więc szyfrowanie jest obowiązkowe. Wygeneruj darmowy certyfikat SSL, włącz w panelu PrestaShop opcje Włącz SSL oraz Wymuś SSL na wszystkich stronach, a dodatkowo wymuś przekierowanie ruchu na HTTPS po stronie serwera zgodnie z artykułem o przekierowaniach i HTTPS.

Zadbaj o konfigurację

• Wyłącz tryb debugowania na działającym sklepie. Tryb deweloperski ujawnia ścieżki i szczegóły konfiguracji, przydatne dla atakującego.
• Chroń pliki konfiguracyjne zawierające dane dostępu do bazy. Nie udostępniaj ich i nie wgrywaj ich kopii do katalogu sklepu.
• Korzystaj z aktualnej wersji PHP, bo starsze wydania nie dostają już poprawek bezpieczeństwa.

Rób kopie zapasowe

Kopia nie zapobiega włamaniu, ale pozwala wrócić do czystego sklepu, gdy coś pójdzie nie tak. Najlepiej trzymać własną kopię (pliki i bazę danych naraz) przechowywaną poza serwerem sklepu. Dodatkowym zabezpieczeniem są automatyczne kopie hostingu, które powstają co godzinę i z których przywrócisz sklep samodzielnie z panelu, co opisujemy w poradniku o kopiach.

Objaw infekcji: 404 na miniaturkach i nadpisany .htaccess

Jeden z częstszych objawów włamania na PrestaShop jest mylący: miniaturki i zdjęcia produktów przestają się wyświetlać, zwracając błąd 404, choć pliki obrazów nadal leżą na serwerze.

Przyczyną bywa złośliwy kod, który nadpisał plik .htaccess w katalogu sklepu. PrestaShop używa .htaccess do tak zwanych przyjaznych adresów URL, w tym do przepisywania adresów miniatur. Gdy infekcja podmieni ten plik (zwykle po to, by dodać własne przekierowania lub furtki), reguły przepisywania przestają działać i obrazki zwracają 404. To znak, że nie chodzi o pojedynczy błąd, tylko o naruszenie bezpieczeństwa sklepu.

Co zrobić w takiej sytuacji:

1. Sprawdź plik .htaccess w katalogu sklepu przez FTP lub menedżer plików. Szukaj nieznanych przekierowań i doklejonego kodu.
2. Nie poprzestawaj na samej poprawie pliku. Skoro .htaccess został nadpisany, sklep jest zainfekowany, więc potraktuj to jak włamanie (sekcja niżej).
3. Odtwórz poprawny .htaccess. Najpewniej przywrócisz go z czystej kopii. Możesz go też wygenerować na nowo: W panelu PrestaShop, w ustawieniach SEO i adresów URL, zapisanie konfiguracji odtwarza plik .htaccess.

Co zrobić po włamaniu

1. Zmień wszystkie hasła: do panelu sklepu, bazy danych, FTP/SSH i panelu klienta.
2. Przywróć sklep z czystej kopii sprzed infekcji, korzystając z poradnika o kopiach. To najpewniejsza droga.
3. Jeśli nie masz czystej kopii, wgraj na nowo rdzeń PrestaShop i moduły ze świeżych, oficjalnych źródeł, a katalog mediów sprawdź pod kątem podejrzanych plików (np. skryptów .php tam, gdzie powinny być tylko obrazy).
4. Zamknij furtkę: zaktualizuj PrestaShop i moduły, usuń dodatki z niepewnych źródeł, odtwórz poprawny .htaccess.
5. Jeśli nie masz pewności, że sklep jest czysty, napisz zgłoszenie. Pomożemy ustalić zakres infekcji i wskazać dalsze kroki. Ogólny schemat naprawy opisujemy też w artykule o naprawie zhakowanej strony.

Najczęstsze pytania

Miniaturki produktów pokazują błąd 404, czy to infekcja?

To częsty objaw infekcji, która nadpisała plik .htaccess i zepsuła przepisywanie adresów. Sprawdź .htaccess pod kątem obcych wpisów. Jeśli został podmieniony, potraktuj to jak włamanie: Przywróć czystą kopię sklepu i zamknij lukę, a nie tylko odtwarzaj sam plik.

Czy webh zabezpiecza mój sklep PrestaShop?

Dbamy o bezpieczeństwo infrastruktury (serwery, sieć, firewall hostingu blokujący znaczną część automatycznych ataków), ale za sam sklep odpowiadasz Ty. Aktualizacje, hasła, moduły i kopie zapasowe pozostają po stronie właściciela sklepu.

Usunąłem złośliwy kod z .htaccess, czy sklep jest już bezpieczny?

Niekoniecznie. Nadpisany .htaccess to znak, że infekcja dostała się do sklepu i mogła zostawić inne furtki. Najpewniejsze jest przywrócenie czystej kopii sprzed włamania i zamknięcie luki, przez którą atakujący wszedł.

Jak najczęściej dochodzi do takiej infekcji?

Najczęściej przez nieaktualny moduł ze znaną luką albo dodatek z nielegalnego źródła z ukrytą furtką. Dlatego aktualizacje i instalowanie modułów wyłącznie z zaufanych źródeł to podstawa ochrony sklepu.