Przejdź do treści
Poradniki · Bezpieczeństwo IT

Bezpieczeństwo sklepu internetowego: lista po roku dyżurów

Sprawdź, jak zadbać o bezpieczeństwo sklepu internetowego na PrestaShop i WooCommerce: lista kontrolna, skan PCI DSS, pierwsza godzina po włamaniu.

Spis treści
  1. Skąd biorą się włamania do sklepów na PrestaShop i WooCommerce
  2. Lista kontrolna bezpieczeństwa sklepu internetowego
  3. Skan PCI DSS: co oznaczają uwagi i co poprawić najpierw
  4. Pierwsza godzina po wykryciu włamania do sklepu
  5. Rutyna miesięczna, która zapobiega większości problemów
  6. FAQ

Bezpieczeństwo sklepu internetowego na PrestaShop czy WooCommerce rzadko pada przez wyrafinowany atak. Częściej przez moduł, którego nikt nie aktualizował od lat, konto administratora po dawnym współpracowniku albo wtyczkę zainstalowaną na chwilę i zostawioną na zawsze. Po roku dyżurów przy sklepach widzę, że te same przyczyny wracają, więc zebrałem je w listę kontrolną: co sprawdzić od razu, jak czytać wyniki skanu PCI DSS, co zrobić w pierwszej godzinie po wykryciu problemu i jaka rutyna miesięczna wystarcza, żeby do niego nie dochodziło.

Tekst jest dla właściciela sklepu albo e-commerce managera, który nie musi znać kodu, ale musi wiedzieć, o co zapytać swojego wykonawcę. Przykłady są ogólne i nie opisują żadnego konkretnego sklepu.

Skąd biorą się włamania do sklepów na PrestaShop i WooCommerce

Większość problemów zaczyna się od tego, co w sklepie doinstalowano, a nie od samej platformy. PrestaShop i WooCommerce mają aktywne zespoły, które łatają rdzeń. Słabym punktem są dodatki: moduły płatności, eksporty do porównywarek, kreatory stron i wtyczki od autorów, którzy przestali je rozwijać.

Trzy wektory widzę najczęściej:

  • Przestarzałe moduły i wtyczki. Dodatek bez aktualizacji ma znaną lukę, a automatyczne skanery szukają jej we wszystkich sklepach naraz. Nie trzeba być ważnym celem, wystarczy mieć starą wersję.
  • Spam SEO wstrzyknięty w treści. Atakujący dopisuje ukryte linki albo całe podstrony z obcymi frazami. Sklep sprzedaje normalnie, a problem wychodzi dopiero w wynikach wyszukiwania albo w Search Console.
  • Porzucone konta administratora. Konto dawnego pracownika, agencji czy freelancera z prostym hasłem i bez drugiego składnika logowania to otwarte drzwi, o których nikt nie pamięta.

Wspólny mianownik jest jeden: nikt nie ma spisu tego, co w sklepie działa i kto ma do niego dostęp. Od tego spisu zaczyna się każda rozmowa o bezpieczeństwie.

Lista kontrolna bezpieczeństwa sklepu internetowego

Poniższe punkty da się przejść w jedno popołudnie razem z wykonawcą. Jeśli na któreś pytanie nikt nie zna odpowiedzi, to jest pierwsza rzecz do zrobienia.

  1. Spis modułów i wtyczek z wersją, datą ostatniej aktualizacji i informacją, czy autor nadal je rozwija.
  2. Usunięcie dodatków nieużywanych, a nie tylko ich wyłączenie.
  3. Lista kont z dostępem do panelu, serwera, bazy i FTP, z właścicielem każdego konta.
  4. Logowanie dwuskładnikowe dla wszystkich administratorów.
  5. Wersja PHP i bazy danych, która ma jeszcze wsparcie, a nie ta, która działa od zawsze.
  6. Kopia zapasowa poza serwerem sklepu i sprawdzenie, że da się z niej odtworzyć sklep.
  7. Monitoring zmian w plikach i alert, gdy w katalogu sklepu pojawi się nowy plik PHP.

Szerzej o ochronie danych w całej firmie, nie tylko w sklepie, piszę w tekście o strategiach zabezpieczania danych firmowych.

Skan PCI DSS: co oznaczają uwagi i co poprawić najpierw

Skan PCI DSS to zewnętrzne sprawdzenie sklepu pod kątem standardu bezpieczeństwa danych kart płatniczych. Wymaga go zwykle operator płatności albo bank, a wykonuje zatwierdzony dostawca skanów (ASV). Wynik przychodzi jako lista uwag z poziomami ważności, często w języku, który niewiele mówi właścicielowi sklepu.

Kolejność poprawek ustalam według ryzyka, nie według długości listy:

  • Najpierw uwagi o znanych lukach w oprogramowaniu: stara wersja serwera WWW, PHP, platformy albo modułu. To je wykorzystują automaty.
  • Potem konfiguracja szyfrowania: przestarzałe wersje protokołu TLS i słabe szyfry.
  • Dalej usługi wystawione do internetu bez potrzeby, na przykład panel bazy danych albo dostęp do serwera z dowolnego adresu.
  • Na końcu uwagi informacyjne, takie jak brakujące nagłówki bezpieczeństwa czy ujawniona wersja oprogramowania.

Część uwag bywa fałszywym alarmem, bo skaner widzi numer wersji, a dostawca serwera wgrał poprawkę bez jego zmiany. Takich pozycji się nie ignoruje. Opisuje się je, dokłada potwierdzenie od dostawcy i zgłasza do ponownej oceny.

Pierwsza godzina po wykryciu włamania do sklepu

W pierwszej godzinie liczy się zatrzymanie szkód i zachowanie śladów, a nie szybkie sprzątanie. Usunięcie podejrzanych plików przed zrobieniem kopii niszczy dowody i utrudnia ustalenie, którędy atakujący wszedł.

  1. Odcięcie: tryb konserwacji albo blokada ruchu, zmiana haseł do panelu, serwera i bazy, wylogowanie wszystkich sesji.
  2. Kopia: pełna kopia plików i bazy w obecnym stanie, zapisana osobno od kopii sprzed incydentu.
  3. Logi: zabezpieczenie logów serwera WWW, panelu i poczty, zanim rotacja je nadpisze.
  4. Operator płatności: zgłoszenie, jeśli istnieje podejrzenie, że zmieniono stronę płatności albo formularze zamówienia.

Jeśli wyciekły dane klientów, dochodzi obowiązek prawny. Administrator danych zgłasza naruszenie do UODO bez zbędnej zwłoki, w miarę możliwości nie później niż w ciągu 72 godzin od jego stwierdzenia, co wynika z art. 33 RODO. Wyjątkiem jest sytuacja, w której ryzyko dla osób jest mało prawdopodobne, ale tę ocenę trzeba umieć uzasadnić. Dopiero po tych krokach przychodzi czas na analizę, czyszczenie i odtworzenie sklepu z czystej kopii.

Rutyna miesięczna, która zapobiega większości problemów

Bezpieczeństwo sklepu internetowego to nie jednorazowy projekt, tylko powtarzalna czynność wpisana w kalendarz. Przegląd raz w miesiącu wystarcza, jeśli między przeglądami działa monitoring.

  • Aktualizacje platformy, modułów i motywu, najpierw na kopii sklepu, potem na produkcji.
  • Przegląd kont administratorów i usunięcie tych, które nie są już potrzebne.
  • Kontrola, czy kopie zapasowe powstają, i co jakiś czas próbne odtworzenie.
  • Przegląd alertów z monitoringu dostępności i zmian w plikach.
  • Sprawdzenie Search Console pod kątem obcych podstron i ostrzeżeń o bezpieczeństwie.

Kto ma to robić, zapisz w umowie utrzymaniowej, razem z czasem reakcji na incydent. Jak taką umowę ułożyć, opisałem przy temacie umowy SLA na utrzymanie systemu.

Jeśli nie wiesz, kiedy ostatnio ktoś aktualizował moduły w Twoim sklepie i kto ma konto administratora, zacznij od tych dwóch list. To niewielka praca, a pokazuje, gdzie leży najwięcej ryzyka. Gdy chcesz przejrzeć je z kimś, kto zajmuje się tym na co dzień, i ułożyć stałą rutynę, zajrzyj na stronę o zasadach współpracy ze mną. Bezpieczeństwo sklepu internetowego zaczyna się od wiedzy, co w nim właściwie działa.

FAQ

Czy sklep na hostingu współdzielonym może być bezpieczny?

Może, jeśli dostawca utrzymuje aktualne wersje PHP i bazy, a sklep ma kopie poza serwerem i monitoring zmian w plikach. Ryzyko rośnie, gdy na tym samym koncie leżą stare, porzucone strony, bo luka w jednej z nich daje dostęp do wszystkich plików.

Jak poznać, że w sklepie jest wstrzyknięty spam SEO?

Najprościej w Search Console: obce frazy w raporcie skuteczności, nieznane podstrony w indeksie albo ostrzeżenie o bezpieczeństwie. Pomaga też wyszukanie w Google adresu sklepu razem ze słowami, które nie mają nic wspólnego z ofertą.

Czy wystarczy wyłączyć nieużywaną wtyczkę zamiast ją usuwać?

Nie zawsze. Pliki wyłączonej wtyczki nadal leżą na serwerze i część z nich da się wywołać bezpośrednio z przeglądarki. Dodatek, który nie jest potrzebny, lepiej usunąć razem z plikami, a przed usunięciem zrobić kopię.

Krzysztof Balicki
CEO & CTO Web Systems

Buduję oprogramowanie od 1999 r. Z zespołem Web Systems projektuję i wdrażam systemy dla firm – coraz częściej z agentami AI.

Nie wiesz, kto ma dziś konto administratora w Twoim sklepie i kiedy ostatnio aktualizowano moduły? Umów rozmowę

Powiązane wpisy