Zabezpieczanie sklepu PrestaShop: Praktyczny przewodnik dla właścicieli sklepów

Prowadzenie sklepu internetowego to prawdziwe pieniądze i prawdziwe dane klientów. To sprawia, że jesteś celem — nie dlatego, że jesteś wyjątkowy, ale dlatego, że zautomatyzowane boty nieustannie skanują każdą instalację WordPress, Magento i PrestaShop w sieci w poszukiwaniu znanych luk. Dobra wiadomość: większość ataków udaje się przez podstawowe błędy, a podstawowe błędy da się naprawić. Ten poradnik omawia to, co naprawdę ma znaczenie, w kolejności, w jakiej naprawdę ma znaczenie.

SSL: masz go, ale czy działa poprawnie?

Każdy sklep ma dziś certyfikat SSL. Większość ma go źle skonfigurowanego. Kłódka w przeglądarce oznacza tylko, że sama strona załadowała się przez HTTPS — nie że cały sklep jest zaszyfrowany. Ukryty problem to mieszana zawartość (mixed content): obrazy, skrypty lub arkusze stylów ładowane przez zwykłe HTTP na stronie HTTPS. Przeglądarki blokują je po cichu, psując funkcjonalność bez wyraźnych komunikatów o błędach.

Otwórz Chrome DevTools na stronie głównej, przejdź do konsoli i poszukaj ostrzeżeń "Mixed Content". Usuń je, aktualizując zakodowane na stałe adresy http:// w motywie, modułach lub ustawieniach bazy danych. W PrestaShop sprawdź w Parametry sklepu → Ogólne, czy zarówno domena sklepu, jak i domena SSL wskazują na Twój adres HTTPS.

Sprawdź też, czy przekierowanie z HTTP na HTTPS działa na poziomie serwera — nie tylko wewnątrz PrestaShop. Jeśli ktoś wejdzie na http://yourstore.com, powinien otrzymać przekierowanie 301 do https://yourstore.com jeszcze zanim PrestaShop się załaduje. Zajrzyj do .htaccess — reguła przekierowania powinna być przed regułami rewrite PrestaShop, nie zakopana w ich środku.

Twój adres panelu administracyjnego nie jest tajemnicą

Każda domyślna instalacja PrestaShop umieszcza panel administracyjny pod /admin z losowym sufiksem generowanym podczas instalacji. Ten sufiks nie jest zabezpieczeniem — to tylko drobna przeszkoda. Boty systematycznie sprawdzają typowe wzorce. Twój adres admina jest o wiele mniej ukryty, niż myślisz.

Zmień nazwę katalogu admina na coś, co nie zawiera słowa "admin". Wybierz coś bez znaczenia — unikaj słownikowych słów w ogóle. To nie powstrzyma zdeterminowanego atakującego z dostępem do Twoich plików, ale natychmiast eliminuje masowe automatyczne skanowanie.

Jeśli Twój hosting obsługuje whitelisting IP przez .htaccess, skorzystaj z tego. Dodaj dyrektywę Require ip w .htaccess folderu admin, żeby zezwolić tylko na adresy IP biura i domu. Tak, to niewygodne podczas podróży. Tak, warto.

Konta pracowników: jedna osoba, jedno konto, bez wyjątków

Współdzielone konta administratora to jedna z najczęstszych przyczyn incydentów bezpieczeństwa — i najtrudniejsza do wyjaśnienia po fakcie. Gdy wszyscy pracownicy logują się jako "admin", nie masz żadnego śladu audytu. Nie możesz ustalić, kto usunął produkt, kto zmienił cenę, ani kto wyeksportował listę klientów o 2 w nocy.

Utwórz indywidualne konta dla każdej osoby potrzebującej dostępu do back-office. Korzyśtaj właściwie z profili uprawnień PrestaShop: pracownik obsługi klienta nie potrzebuje dostępu do ustawień płatności. Operator magazynu nie potrzebuje dostępu do zarządzania pracownikami. Zasada minimalnych uprawnień to nie biurokracja — ogranicza zasięg szkód, gdy konto zostanie przejęte.

Audytuj listę pracowników co kwartał. Usuwaj konta osób, które już u Ciebie nie pracują. Byli pracownicy z aktywnymi danymi dostępowymi to realny wektor ryzyka, i taki, nad którym masz pełną kontrolę.

Bezpieczeństwo modułów: powierzchnia ataku, której nie pilnujesz

Moduły to najczęstszy punkt wejścia przy włamaniach do sklepów PrestaShop. Podatny moduł — nawet taki, którego aktywnie nie używasz — może zostać wykorzystany, jeśli jest zainstalowany i włączony. Atakujących nie obchodzi, że nie dotykałeś tego modułu płatności od dwóch lat. Jeśli jest tam i ma lukę, jest otwartymi drzwiami.

Instaluj moduły tylko ze sprawdzonych źródeł. Marketplace PrestaShop Addons weryfikuje przesłane moduły — losowe strony trzecie i przypadkowe repozytoria GitHub już nie. Moduły nulled — płatne moduły dystrybuowane nielegalnie za darmo — prawie zawsze zawierają backdoory. Logika jest prosta: dlaczego ktoś miałby rozdawać płatne oprogramowanie za darmo? Bo coś do niego dodał.

Usuwaj moduły, których nie używasz. Nie tylko wyłączaj — odinstalowuj i kasuj pliki. Każdy zainstalowany moduł dodaje kod ładowany przy każdym żądaniu, zwiększając zarówno powierzchnię ataku, jak i czas ładowania strony. Zrób audyt modułów: jeśli nie używałeś czegoś od sześciu miesięcy i nie planujesz — wyrzuć to.

Regularnie aktualizuj moduły. Większość luk bezpieczeństwa w modułach jest łatana szybko po odkryciu — ale łatka pomaga tylko wtedy, gdy ją zainstalowasz. Nasz moduł Security Revolution zawiera monitorowanie integralności plików, które wykrywa nieoczekiwane zmiany w plikach Twoich modułów, a nasz moduł Total Defender dodaje aktywne warstwy ochrony, w tym blokowanie botów i logowanie podejrzanej aktywności.

Kopie zapasowe bazy danych: jedyna gwarancja odtworzenia

Kopie zapasowe to nie środek bezpieczeństwa — to środek odtworzeniowy. Ta różnica jest ważna, bo zmienia sposób myślenia o nich. Żadna strategia backupów nie zapobiega atakowi. Dobre kopie zapasowe sprawiają, że atak nie kończy Twojego biznesu.

Zautomatyzuj swoje kopie zapasowe. Ręczne backupy są pomijane, odkładane i zapominane. Ustaw cron job, który co noc eksportuje bazę danych i kopiuje ją poza serwer. "Poza serwer" oznacza miejsce, w którym przejęcie serwera www nie kompromituje jednocześnie kopii zapasowych — oddzielny bucket chmurowy, lokalny komputer, gdziekolwiek poza maszyną, która mogłaby zostać wyczyszczona.

Testuj przywracanie. Kopia zapasowa, której nigdy nie przywróciłeś, nie jest kopią zapasową — to plik o nieznanej zawartości. Przeprowadź testowe przywracanie na środowisku stagingowym co najmniej raz na kwartał. Nie chcesz, żeby pierwszym razem, gdy przywracasz z backupu, był prawdziwy incydent.

Przechowuj wiele punktów przywracania. Codzienne kopie z ostatnich 30 dni, tygodniowe z ostatnich sześciu miesięcy. Niektóre ataki — zwłaszcza manipulacja bazą danych — nie są odkrywane natychmiast. Musisz móc przywrócić stan sprzed początku kompromitacji.

Hasła i uwierzytelnianie dwuskładnikowe

PrestaShop obsługuje uwierzytelnianie dwuskładnikowe natywnie od wersji 1.7.6. Jeśli nie używasz go dla kont administratorów, włącz je dziś. Konfiguracja zajmuje pięć minut. Przejdź do swojego profilu w back-office i włącz 2FA za pomocą aplikacji uwierzytelniającej, takiej jak Google Authenticator lub Authy.

Wymagaj 2FA dla wszystkich kont administratora, nie tylko swojego. Pracownik ze słabym hasłem i bez 2FA to najsłabsze ogniwo w Twoim łańcuchu bezpieczeństwa.

W kwestii haseł: używaj menedżera haseł i generuj długie, losowe hasła dla każdego konta. "Długie" oznacza co najmniej 20 znaków dla kont administratora. Nigdy nie używaj ponownie haseł w różnych serwisach. Twoje hasło administratora PrestaShop nie powinno pojawiać się nigdzie indziej — ani w panelu hostingu, ani w poczcie e-mail, ani na koncie marketplace modułów.

Uprawnienia plików: podstawy wciąż mają znaczenie

Prawidłowe uprawnienia plików dla instalacji PrestaShop to 755 dla katalogów i 644 dla plików. Jeśli Ty lub Twój hosting kiedykolwiek ustawiliście uprawnienia na 777 "żeby naprawić problem", wróć i napraw to właściwie. Pliki z uprawnieniami zapisu dla wszystkich oznaczają, że dowolny proces na serwerze — w tym kod wstrzyknięty przez lukę — może je modyfikować.

Sprawdź uprawnienia konkretnie pliku config/settings.inc.php. Zawiera dane dostępowe do bazy danych. Powinien mieć 444 lub 640 — czytelny dla serwera www, niezapisywalny przez nikogo.

Na hostingu współdzielonym profil ryzyka jest wyższy, bo dzielisz serwer z innymi stronami. Przejęcie innej strony na Twoim serwerze może potencjalnie wpłynąć na Twoją, jeśli uprawnienia są zbyt otwarte. To jeden z prawdziwych argumentów za VPS zamiast hostingu współdzielonego dla sklepów obsługujących realny wolumen transakcji.

Utrzymuj PrestaShop i PHP na bieżąco

Stare wersje PHP nie tylko działają wolniej — przestają otrzymywać łatki bezpieczeństwa. PHP 7.4 osiągnął koniec życia w listopadzie 2022 roku. Jeśli Twój hosting nadal go używa (a wiele hostingów współdzielonych wciąż tak robi), masz na serwerze znane, niezałatane luki w środowisku uruchomieniowym. Sprawdź swóją wersję PHP w back-office PrestaShop pod Zaawansowane parametry → Informacje.

PrestaShop wydaje łatki bezpieczeństwa w wersjach pomniejszych. Działanie na 8.1.0, gdy dostępna jest 8.1.7, oznacza znane dziury bezpieczeństwa. Aktualizacje głównych wersji wymagają więcej ostrożności, ale mniejsze aktualizacje w obrębie tej samej gałęzi są generalnie bezpieczne i powinny być stosowane szybko po wykonaniu kopii zapasowej i przetestowaniu na stagingu.

Hartowanie .htaccess

Domyślny .htaccess PrestaShop to punkt wyjścia, nie gotowa konfiguracja bezpieczeństwa. Dodaj poniższe reguły, żeby zablokować bezpośredni dostęp do katalogów, które nigdy nie powinny być publicznie dostępne:

• Zablokuj bezpośredni dostęp do /config/ — zawiera dane dostępowe do bazy i klucze szyfrowania
• Zablokuj bezpośredni dostęp do /var/ — zawiera pliki cache i logi
• Zablokuj bezpośredni dostęp do /vendor/ — zawiera pliki bibliotek zewnętrznych
• Zablokuj bezpośredni dostęp do /src/ — zawiera podstawowe pliki źródłowe
• Zablokuj wykonywanie plików PHP wewnątrz /upload/ — częsty cel uploadu złośliwego oprogramowania

Dla katalogu upload konkretnie: dodaj .htaccess wewnątrz /upload/, który blokuje wykonywanie PHP. Jeśli atakujący wgra shell PHP przez lukę w uploading plików, ta reguła uniemożliwi mu jego uruchomienie.

RODO i bezpieczeństwo ciasteczek

Bezpieczeństwo ciasteczek to nie tylko kwestia zgodności z przepisami — nieprawidłowo skonfigurowane ciasteczka mogą ujawniać tokeny sesji i dane uwierzytelnienia. Upewnij się, że ciasteczka sesyjne mają ustawioną flagę Secure (przesyłane tylko przez HTTPS) i flagę HttpOnly (niedostępne dla JavaScript). Jeśli potrzebujesz prawidłowej implementacji zgody na ciasteczka zgodnej z RODO, która nie psuje funkcjonalności sklepu, nasz moduł Cookies Revolution robi to właściwie.

Jeśli zostaniesz zhakowany: co naprawdę robić

Po pierwsze: nie panikuj, ale działaj szybko. Każda godzina zwłoki to więcej potencjalnych szkód.

Natychmiast izoluj. Wyłącz sklep lub włącz tryb konserwacji. Jeśli Twój hosting ma opcję "zawieś stronę", użyj jej. Najpierw zatrzymaj krwawienie, potem diagnozuj ranę.

Jeszcze nic nie usuwaj. Instynkt podpowiada: sprzątać. Ale musisz zachować dowody, żeby zrozumieć, co się stało. Zrób pełną kopię zapasową skompromitowanego stanu zanim zaczniesz usuwać pliki.

Sprawdź daty modyfikacji plików. Wyszukaj pliki modyfikowane w ciągu ostatnich 30 dni. Porównaj z historią wdrożeń. Pliki, które zmieniły się bez odpowiadającej im aktualizacji, to wskaźniki kompromitacji. Szczególną uwagę zwróć na pliki PHP w /upload/, /img/ i katalogach modułów — tam, gdzie zapisy plików są oczekiwane i łatwiej je ukryć.

Przywróć z czystej kopii zapasowej. Nie próbuj chirurgicznie usuwać złośliwego oprogramowania z działającej strony — atakujący są dobrzy w ukrywaniu backdoorów i na pewno coś pominiesz. Przywróć z kopii zapasowej, co do której masz pewność, że pochodzi sprzed kompromitacji.

Zmień wszystkie hasła. Hasło bazy danych, dane FTP, panel hostingu, konta administratora PrestaShop, konta e-mail powiązane z domeną. Zakładaj, że wszystko było czytelne w czasie trwania kompromitacji.

Znajdź punkt wejścia. To ważne, żeby zapobiec powtórce. Typowe punkty wejścia: podatny moduł, przejęte dane dostępowe pracownika, hasło admina złamane brute-forcem. Jeśli nie uda Ci się ustalić, jak to się stało, stanie się ponownie.

Powiadom właściwe podmioty. Jeśli uzyskano dostęp do danych klientów — adresów e-mail, historii zamówień, danych płatniczych — prawdopodobnie masz prawne obowiązki powiadamiania zależnie od jurysdykcji. RODO wymaga powiadomienia w ciągu 72 godzin od stwierdzenia naruszenia. Nie zwlekaj z tym.

Bezpieczeństwo to nie funkcja, którą dodajesz raz i zapominasz. To konserwacja — jak utrzymywanie aktualnych treści w sklepie czy dokładność stanów magazynowych. Ustaw kwartalny przypomnienie, żeby audytować konta pracowników, sprawdzać aktualizacje modułów i weryfikować, czy kopie zapasowe rzeczywiście się przywracają. Dwadzieścia minut co trzy miesiące to znacznie tańsze niż recovery po włamaniu.

Powiązane Artykuły

• Bezpieczenstwo platnosci w PrestaShop: PCI Compliance, 3D Secure i zapobieganie oszustwom
• Bezpieczenstwo PrestaShop: Kompletna lista kontrolna hartowania
• Reakcja na wyciek danych: co robić, gdy Twój sklep zostanie zhakowany