Bezpieczeństwo PrestaShop: podatności CVE, objawy ataku i co zrobić

Większość włamań do sklepów nie zaczyna się od wyrafinowanego ataku na jądro, tylko od starego modułu ze znaną luką. Bezpieczeństwo PrestaShop opiera się na kilku prostych zasadach: aktualne jądro, moduły i PHP, sprawdzanie zainstalowanych modułów pod kątem znanych podatności (CVE), osobne konta i silne hasła w panelu, poprawne uprawnienia plików oraz regularna kopia zapasowa. Poniżej znajdziesz, gdzie sprawdzać podatności, jak rozpoznać, że sklep został zhakowany, i co zrobić krok po kroku po ataku.

Skąd biorą się włamania do sklepów PrestaShop?

Sklep internetowy to łatwy cel: przechodzą przez niego dane klientów i płatności, a wiele sklepów działa latami bez aktualizacji. Najczęstsze drogi ataku:

• Podatne moduły zewnętrzne. Najczęściej podatność SQL injection w kontrolerze lub skrypcie AJAX modułu, który można wywołać bez logowania. Atakujący odczytuje wtedy bazę albo dopisuje do niej własny kod.
• Nieaktualne jądro PrestaShop. Luki w samym PrestaShop zdarzają się rzadziej, ale są dobrze opisane i automatycznie skanowane. W lipcu 2022 roku PrestaShop wydał wersję 1.7.8.7, łatającą podatność CVE-2022-36408, przez którą w wielu sklepach pojawiły się fałszywe formularze płatności.
• Słabe lub wykradzione hasła do panelu, FTP, SSH albo panelu hostingu.
• Pozostałości: katalog instalacyjny, kopie bazy w katalogu publicznym, stare skrypty importu, odinstalowane moduły, których pliki nadal leżą na serwerze.

Ważna rzecz, o której wiele osób nie wie: wyłączenie albo odinstalowanie modułu nie usuwa jego plików. Jeśli moduł ma samodzielny skrypt PHP z luką, nadal da się go wywołać z przeglądarki. Nieużywane moduły usuwaj z dysku.

Podatności PrestaShop (CVE): gdzie je sprawdzić?

Znane podatności dostają numery CVE i są publikowane w kilku miejscach:

• Friends of Presta prowadzi publiczną listę ostrzeżeń bezpieczeństwa, głównie dla modułów: security.friendsofpresta.org. Każdy wpis podaje nazwę modułu, podatne wersje, wersję z poprawką (jeśli istnieje) i numer CVE.
• PrestaShop publikuje ostrzeżenia dotyczące jądra w repozytorium projektu: github.com/PrestaShop/PrestaShop/security/advisories.

Jak sprawdzić swój sklep:

1. W Moduły → Menedżer modułów spisz zainstalowane moduły i ich wersje. Nie zapomnij o modułach wyłączonych.
2. Porównaj listę z ostrzeżeniami Friends of Presta. Szukaj po nazwie technicznej modułu (nazwie katalogu w /modules), nie po nazwie handlowej.
3. Dla podatnych modułów zainstaluj wersję z poprawką od autora. Jeśli poprawki nie ma albo autor zniknął, moduł trzeba usunąć, zastąpić innym albo załatać samodzielnie.
4. Wersję jądra sprawdzisz w Zaawansowane → Informacja i porównasz z ostrzeżeniami PrestaShop.

Osobny problem stanowią moduły z zaciemnionym (zakodowanym) kodem. Nie da się ich rzetelnie przejrzeć: ani ty, ani audytor nie widzicie, co robią i czy nie zawierają luki. Nasze moduły mają czytelny kod bez DRM i zaciemniania, więc każdy programista może go sprawdzić.

Jak aktualizować PrestaShop, żeby było bezpiecznie?

Aktualizacje to najtańsze zabezpieczenie, a jednocześnie najczęściej odkładane. Zadbaj o trzy warstwy:

• Jądro PrestaShop. PrestaShop 1.6 od lat nie dostaje poprawek, a różnice między 1.7 a 8 i 9 są duże. Jeśli zostajesz na 1.7, instaluj przynajmniej ostatnią wersję z tej linii. Plan przejścia opisujemy w poradniku Jak zaktualizować PrestaShop, a jeśli wolisz to zlecić, mamy aktualizację PrestaShop w stałej cenie.
• Moduły i motyw. Sprawdzaj aktualizacje u autorów, zwłaszcza modułów płatności, eksportów i formularzy, czyli wszystkiego, co przyjmuje dane od odwiedzających.
• PHP i serwer. PHP 7.4 i 8.0 nie dostają już poprawek bezpieczeństwa. Wersję PHP i bazy danych też zobaczysz w Zaawansowane → Informacja.

Każdą aktualizację poprzedź kopią plików i bazy oraz testem na kopii sklepu.

Panel administracyjny i konta pracowników

Panel to najcenniejszy cel, bo daje pełną kontrolę nad sklepem.

• Nazwa katalogu admina. Instalator zwykle nadaje mu losową nazwę. Nie zmieniaj jej na admin, panel ani nazwę sklepu.
• Usunięty katalog install. Po instalacji nie może zostać na serwerze, tak samo jak stare kopie i archiwa ZIP sklepu.
• Osobne konta. Każda osoba ma własne konto w Zaawansowane → Zespół → Pracownicy, z profilem i uprawnieniami ograniczonymi do tego, czego potrzebuje. Konto agencji czy byłego pracownika wyłącz od razu po zakończeniu współpracy.
• Silne, unikalne hasła i menedżer haseł. W PrestaShop 8 i 9 politykę haseł ustawisz w Zaawansowane → Bezpieczeństwo, a w Sesje pracowników zobaczysz aktywne sesje i usuniesz te podejrzane.
• Dodatkowa bariera. Hosting zwykle pozwala ograniczyć dostęp do katalogu admina do wybranych adresów IP albo dodać drugie hasło na poziomie serwera.
• Klucze API. W Zaawansowane → API usuń nieużywane klucze, a pozostałym zostaw tylko niezbędne uprawnienia.
• Ochrona tokenem w panelu powinna pozostać włączona.

Uprawnienia plików i konfiguracja serwera

Typowe, bezpieczne ustawienia to 755 dla katalogów i 644 dla plików, nigdy 777. Pliki konfiguracyjne z hasłem do bazy (app/config/parameters.php w PrestaShop 1.7 i nowszych) powinny być czytelne tylko dla użytkownika, na którym działa sklep.

PrestaShop dostarcza pliki .htaccess, które m.in. w katalogu zdjęć img blokują dostęp do plików innych niż obrazy. Działają jednak tylko na Apache. Na nginx te same reguły musi dopisać administrator serwera, inaczej wgrany przez lukę plik PHP w katalogu zdjęć zostanie wykonany.

Na produkcji wyłącz też tryb debugowania, listowanie katalogów i wyświetlanie błędów PHP odwiedzającym, a kopie bazy trzymaj poza katalogiem publicznym.

Jak poznać, że PrestaShop został zhakowany?

Włamanie rzadko jest widoczne od razu. Typowe objawy:

• Skimmer płatności. Na etapie płatności pojawia się dodatkowy formularz karty albo skrypt z obcej domeny. Często pierwszym sygnałem są klienci zgłaszający nadużycia na kartach po zakupie.
• Nieznani pracownicy w Zaawansowane → Zespół → Pracownicy albo zmienione adresy e-mail istniejących kont.
• Zmienione pliki. Nowe pliki PHP w img, upload, modules czy w katalogu motywu, zmienione index.php albo pliki z długimi ciągami base64_decode i eval.
• Spam. Serwer wysyła masowo e-maile, w Google pojawiają się podstrony z obcymi frazami, a odwiedzający z wyszukiwarki są przekierowywani na inne strony.
• Ostrzeżenia z zewnątrz. Komunikat o problemach z bezpieczeństwem w Google Search Console, blokada od operatora płatności albo hostingu.
• Nagłe obciążenie serwera i podejrzane wpisy w Zaawansowane → Logi.

Szybka kontrola jądra: w Zaawansowane → Informacja sekcja Lista zmienionych plików porównuje pliki PrestaShop z oryginalnymi dla twojej wersji. Nie obejmuje modułów zewnętrznych ani motywu, ale szybko pokaże podmienione pliki jądra.

Co zrobić po włamaniu do sklepu PrestaShop?

Działaj po kolei. Pośpieszne kasowanie plików często usuwa ślady, które pozwalają znaleźć lukę.

1. Ogranicz szkody. Włącz przerwę techniczną w Preferencje → Ogólny → Przerwa techniczna albo wyłącz zagrożoną metodę płatności.
2. Zabezpiecz dowody. Zrób kopię plików, bazy i logów serwera w stanie zastanym, zanim cokolwiek zmienisz.
3. Zmień wszystkie hasła i klucze: konta pracowników, baza danych, FTP i SSH, panel hostingu, klucze API sklepu i klucze u operatorów płatności. Usuń nieznane konta.
4. Znajdź wejście. Przejrzyj logi dostępu (zapytania do modułów tuż przed pierwszymi zmianami), porównaj pliki z czystymi kopiami tej samej wersji i sprawdź moduły z listą podatności.
5. Wyczyść albo odtwórz sklep. Jeśli masz czystą kopię sprzed infekcji, odtwórz ją, a potem dograj brakujące zamówienia. Bez załatania luki atak wkrótce się powtórzy.
6. Załataj i zaktualizuj. Usuń podatne i nieużywane moduły, zaktualizuj jądro, moduły i PHP.
7. Powiadom operatora płatności i hosting. Kwestię zgłoszenia naruszenia danych osobowych omów z prawnikiem lub inspektorem ochrony danych.
8. Monitoruj pliki, konta i logi przez kolejne tygodnie, a w Google Search Console poproś o ponowne sprawdzenie witryny.

Jeśli po czyszczeniu sklep pokazuje białą stronę lub błąd 500, pomoże poradnik Biała strona i błąd 500 w PrestaShop. Na przyszłość ustaw automatyczne kopie plików i bazy danych, przechowywane poza serwerem sklepu.

Jak zadbać o bezpieczeństwo PrestaShop na co dzień?

Jeśli nie masz na to czasu, audyt i naprawa bezpieczeństwa sklepu obejmuje sprawdzenie jądra i modułów pod kątem CVE, kontrolę serwera, panelu i uprawnień oraz naprawę podatnych elementów.

Najczęściej zadawane pytania

Podejrzewasz włamanie albo chcesz sprawdzić sklep zawczasu? Napisz do nas — podpowiemy, od czego zacząć.

Produkty z tego wpisu

Audyt i naprawa bezpieczeństwa sklepu

1 499,00 €

Ocena na 5 gwiazdek na podstawie () opinii

Dodaj do koszyka

Wróć do: Blog