Ta checklista bezpieczeństwa sklepu PrestaShop powstała z audytów, które robimy po włamaniach i przed aktualizacjami. Punkty ułożyliśmy od rzeczy, które sprawdzisz w kwadrans, po takie, które wymagają zajrzenia na serwer. Jeżeli przy którymś punkcie odpowiedź brzmi „nie wiem”, potraktuj to jako wynik, a nie brak wyniku.
Wersja i aktualizacje
- Znasz dokładną wersję PrestaShop, na której działa sklep, i wiesz, czy wciąż dostaje poprawki bezpieczeństwa. Gałąź 1.7 już ich nie dostaje — co z tego wynika, opisaliśmy w tekście o sklepach na porzuconym PrestaShop 1.7.
- Moduły mają aktualne wydania, a te porzucone przez autorów są wyłączone albo zastąpione. Głośne podatności ostatnich lat wchodziły przez moduły, nie przez rdzeń.
- Wersja PHP na serwerze jest wspierana przez dostawcę języka, nie tylko „działa”.
Konta i dostępy
- Lista SuperAdminów w panelu ma tylu członków, ilu faktycznie pracuje przy sklepie. Konta byłych agencji i podwykonawców są usunięte, a nie „na wszelki wypadek”.
- Adres panelu administracyjnego nie jest domyślny, a do logowania używacie menedżera haseł zamiast jednego hasła w trzech miejscach.
- Dostępy FTP/SFTP i do bazy mają osobne konta per osoba lub firma. Po zakończeniu współpracy hasła są rotowane.
Serwer i narzędzia publiczne
- phpMyAdmin, adminer i podobne narzędzia nie są dostępne publicznie z katalogu sklepu. To jeden z najczęstszych punktów wejścia, jakie znajdujemy przy audytach.
- Na koncie hostingowym nie leżą stare instalacje: kopie sprzed migracji, wersje testowe, porzucone serwisy. Jedna zapomniana instalacja z dziurą daje zapis w całym koncie.
- Certyfikat SSL odnawia się automatycznie, a sklep wymusza HTTPS na każdej stronie, nie tylko w koszyku.
- Katalogi z uploadami nie pozwalają na wykonywanie plików PHP.
Kopie zapasowe i monitoring
- Backup obejmuje pliki i bazę, wykonuje się automatycznie i trafia poza serwer produkcyjny. Kopia leżąca obok sklepu ginie razem z nim.
- Odtworzenie z kopii było kiedykolwiek przetestowane. Backup, którego nikt nie próbował przywrócić, to hipoteza.
- Ktoś regularnie przegląda pliki sklepu pod kątem rzeczy, których tam być nie powinno: plików udających skrypty, nieznanych modułów, zmian w plikach rdzenia.
- Maile transakcyjne dochodzą, a domena nie wisi na żadnej czarnej liście. Nagłe problemy z dostarczalnością bywają pierwszym widocznym objawem przejętego sklepu.
Co zrobić z wynikami tej checklisty?
Kilka „nie” w części o kontach i narzędziach publicznych załatwisz we własnym zakresie w jedno popołudnie. Gorzej, jeśli „nie” pada przy wersji PrestaShop — wtedy właściwą odpowiedzią jest aktualizacja do PrestaShop 8, bo żadne łatanie dookoła nie zastąpi wspieranej wersji. A jeśli któryś punkt wygląda u Ciebie podejrzanie już teraz, zacznij od audytu bezpieczeństwa Prestashop: robimy go w trybie wyłącznie do odczytu i kończymy raportem z priorytetami, w tym wyceną ewentualnej migracji (ile kosztuje aktualizacja PrestaShop).
