Twój sklep jest atakowany właśnie teraz. Nie "może być", nie "kiedyś" - w tej samej chwili zautomatyzowane skrypty skanują każdą polską domenę w poszukiwaniu podatności. Boty nie potrzebują człowieka przy klawiaturze. Działają 24/7 i są znacznie cierpliwsze niż jakikolwiek administrator sklepu internetowego.
W tym artykule pokazuję Ci dokładnie to, co widzi atakujący w ciągu pierwszych minut od namierzenia Twojego sklepu. Bez paniki, bez straszenia na wyrost. Tylko techniczne fakty, które pomogą Ci podjąć konkretne decyzje.
Jak wygląda automatyczny skan sklepu - krok po kroku
Zanim atakujący wykona pierwszy ruch, jego skrypt już wie o Twoim sklepie więcej, niż myślisz. Cały proces fingerprintingu - czyli identyfikacji środowiska technicznego - zajmuje od kilku do kilkudziesięciu sekund i odbywa się bez logowania, bez żadnych uprawnień, całkowicie pasywnie.
Krok 1: Identyfikacja platformy
Bot wysyła żądanie GET na kilka charakterystycznych ścieżek. Wystarczy, że jedna z nich zwróci odpowiedź inną niż "404 Not Found", by skrypt wiedział, że ma do czynienia z PrestaShop. Najczęściej sprawdzane pliki i katalogi to:
/modules//themes//img//INSTALL.txt/CHANGELOG.txt
Szczególnie cenny dla atakującego jest plik CHANGELOG.txt. W starszych instalacjach PrestaShop zawiera on pełną historię wersji - dzięki temu haker poznaje dokładną wersję Twojego silnika bez jakiegokolwiek włamania.
Krok 2: Nagłówki HTTP zdradzają więcej, niż myślisz
Każda odpowiedź Twojego serwera zawiera nagłówki HTTP. Nieodpowiednio skonfigurowany serwer ujawnia w nich wersję PHP, nazwę serwera WWW (Apache/Nginx) wraz z wersją, a czasem nawet używany framework.
Możesz to sprawdzić samodzielnie: otwórz DevTools w przeglądarce (F12), przejdź do zakładki Network, odśwież stronę główną sklepu i zajrzyj do sekcji nagłówków (Headers) odpowiedzi.
Krok 3: Mapa zainstalowanych modułów
To jest informacja, za którą atakujący są gotowi zapłacić. Moduły PrestaShop ładują swoje zasoby (CSS, JS, obrazki) z dedykowanych katalogów, np. /modules/nazwa_modulu/. Te ścieżki są widoczne w kodzie źródłowym dla każdego, kto kliknie "Pokaż źródło strony".
W ciągu niespełna minuty skrypt buduje listę kilkudziesięciu modułów zainstalowanych w Twoim sklepie, a następnie automatycznie porównuje ją z bazą znanych podatności (CVE).
Krok 4: Sprawdzenie URL panelu administracyjnego
Domyślny adres logowania do panelu w PrestaShop to katalog /admin z losowym sufiksem generowanym podczas instalacji - na przykład /admin4x7k2/. Problem polega na tym, że wiele instalacji, szczególnie tych migrowanych ze starszych wersji lub kopiowanych między środowiskami przez niedoświadczonych programistów, zachowuje przewidywalne nazwy. Bot w ułamku sekundy sprawdza kilkaset najpopularniejszych kombinacji.
Co atakujący widzi w 30 sekund?
Po wykonaniu podstawowego, całkowicie pasywnego skanowania, skrypt generuje gotowy raport o Twoim sklepie:
Wersja PrestaShop: wyciągnięta z plików changelog lub meta tagów.
Wersja PHP: odczytana z nagłówka X-Powered-By (jeśli nie został wyłączony).
Lista modułów: wyekstrahowana z kodu źródłowego widoku strony.
Status URL admina: informacja, czy jest domyślny, czy niestandardowy.
Status SSL: sprawdzenie, czy certyfikat HTTPS jest rygorystycznie wymuszony.
Tryb debug: weryfikacja, czy sklep działa w trybie deweloperskim (co jest krytycznym błędem, ujawniającym ścieżki plików serwera i szczegóły błędów).
Żadna z tych informacji nie wymaga włamania. Wszystkie są publicznie dostępne.
Najpopularniejsze luki w modułach PrestaShop - co mówią dane CVE
Projekt Friends of Presta Security regularnie zbiera i publikuje podatności specyficzne dla tego ekosystemu. Przeglądając ich bazę, można zauważyć wyraźny wzorzec: zdecydowana większość krytycznych luk nie dotyczy rdzenia samego PrestaShop, ale modułów firm trzecich.
Najczęstsze typy ataków to:
SQL Injection: możliwość wykonania dowolnego zapytania do bazy danych przez spreparowany URL lub złośliwy formularz.
XSS (Cross-Site Scripting): wstrzyknięcie złośliwego kodu JavaScript widocznego dla użytkowników sklepu.
Path Traversal: nieautoryzowany dostęp do plików znajdujących się poza publicznym katalogiem webowym.
CSRF: wymuszenie na zalogowanym administratorze wykonania niepożądanych akcji "w tle".
Kluczowa obserwacja: luki w modułach często pozostają aktywne przez miesiące, a nawet lata po ich odkryciu. Dlaczego? Bo właściciele sklepów po prostu nie wiedzą, że wtyczka, za którą zapłacili dwa lata temu, ma dziś oficjalny status "krytyczna podatność".
💡 Nie wiesz, czy moduły w Twoim sklepie mają publicznie znane podatności CVE? Uruchom darmowy skaner i sprawdź to w kilka minut.
Co się dzieje po udanym ataku?
Właściciele e-commerce często wyobrażają sobie atak jako dramatyczne wydarzenie - nagły alarm bezpieczeństwa, wielki czerwony komunikat "strona zhakowana" na stronie głównej i natychmiastowe wstrzymanie sprzedaży. Rzeczywistość jest znacznie bardziej podstępna, ponieważ skuteczne ataki pozostają niezauważone przez całe tygodnie.
Przekierowania na phishing i spam. Złośliwy kod w tle przekierowuje tylko użytkowników mobilnych lub ruch przychodzący z Google na zupełnie inne, zewnętrzne strony. Ty widzisz sklep normalnie, bo logujesz się ze stałego adresu IP, który skrypt omija. Efekt? Drastyczny spadek ruchu organicznego, kara od Google i poirytowani klienci.
Podmiana numerów kont bankowych. Przy płatnościach tradycyjnym przelewem, złośliwy skrypt podmienia numer Twojego rachunku bankowego bezpośrednio na ekranie podsumowania zamówienia. Klient płaci - ale na konto hakera. Dowiadujesz się o tym dopiero wtedy, gdy odzywają się zniecierpliwieni klienci pytający o wysyłkę opłaconego towaru.
Kradzież bazy klientów. Baza danych zawierająca adresy e-mail, numery telefonów, hasła i historię zakupów wędruje na czarny rynek. W świetle przepisów RODO jesteś administratorem tych danych i ponosisz pełną odpowiedzialność za ich wyciek, nawet będąc ofiarą.
Kopalnia kryptowalut. Twój serwer zostaje zaprzęgnięty do kopania kryptowalut dla atakującego. Skutki to dramatyczny wzrost zużycia procesora (CPU), drastyczne spowolnienie ładowania sklepu, gigantyczne rachunki za chmurę, a w skrajnych przypadkach - zablokowanie konta przez dostawcę hostingu.
7 rzeczy, które możesz zrobić jeszcze dziś
Zmień URL panelu administracyjnego. Jeśli Twój back-office znajduje się pod standardową ścieżką z łatwą do odgadnięcia nazwą, natychmiast ją zmień. W PrestaShop robi się to poprzez zmianę nazwy katalogu /admin na serwerze i drobną aktualizację konfiguracji.
Wymuś HTTPS na całej domenie. Szyfrowanie ma działać nie tylko w kasie i przy logowaniu, ale na każdej pojedynczej podstronie. Przejdź do: Preferencje > Ogólne i włącz wymuszenie SSL.
Usuń pliki informacyjne. Pliki CHANGELOG.txt, INSTALL.txt oraz cały katalog /install/ nie mają prawa być dostępne publicznie. Zablokuj do nich dostęp w pliku .htaccess lub fizycznie usuń je z serwera produkcyjnego.
Ukryj wersję PHP w nagłówkach. W pliku konfiguracyjnym php.ini ustaw dyrektywę
expose_php = Off. W ustawieniach serwera WWW (Apache/Nginx) wyłącz opcje ServerTokens oraz ServerSignature.Zaktualizuj wszystkie moduły. Brzmi to banalnie, ale statystyki są bezlitosne: luki w nieaktualizowanych wtyczkach to najczęstszy wektor ataku w całym ekosystemie PrestaShop.
Włącz monitoring CVE. Ręczne sprawdzanie kilkudziesięciu modułów każdego miesiąca jest zadaniem nierealnym. Zainwestuj w automatyczne narzędzie, które powiadomi Cię od razu, gdy w używanym przez Ciebie dodatku zostanie wykryta krytyczna luka.
Skonfiguruj zewnętrzny backup. Jeśli haker przejmie kontrolę nad Twoim serwerem, lokalne kopie zapasowe trzymane na tej samej maszynie stają się bezużyteczne. Twój backup musi trafiać do całkowicie odizolowanej przestrzeni w chmurze.
Podsumowanie
Atakujący nie wybierają swoich ofiar ręcznie. Ich skrypty pracują masowo, automatycznie skanując sieć w poszukiwaniu sklepów z konkretną kombinacją oprogramowania i znanych luk. Twój sklep internetowy nie jest ani "za mały", ani "zbyt mało znany", żeby nie stać się ich celem.
Dobra wiadomość? Większości włamań można zapobiec, stosując podstawowe zasady higieny technicznej i architektonicznej. Zła wiadomość jest taka, że bezpieczeństwo to proces ciągły, a nie jednorazowe kliknięcie w panelu.
Jeśli wolisz skupić się na sprzedaży i rozwoju biznesu zamiast na monitorowaniu logów, śledzeniu baz CVE i aktualizowaniu modułów - sprawdź moją ofertę opieki technicznej w modelu SLA lub skontaktuj się ze mną. Chętnie omówię techniczne zabezpieczenia Twojego e-commerce.
FAQ - Najczęściej zadawane pytania
Czy mój sklep na PrestaShop 8 też jest zagrożony?
Tak. Choć sam rdzeń PrestaShop 8 ma znacznie nowocześniejsze polityki bezpieczeństwa niż wersja 1.7, to podatności w modułach firm trzecich dotyczą wszystkich wersji. Każdy moduł to osobny produkt z własnym, często niedoskonałym cyklem życia i aktualizacji.
Jak sprawdzić, czy mój sklep był już skanowany lub zaatakowany?
Pierwszym krokiem jest dokładna analiza logów serwera (Access Logs). Szukaj podejrzanych żądań HTTP do niestandardowych ścieżek (np. próby dostępu do /vendor/, /config/) oraz nienaturalnie dużej liczby błędów 404 pochodzących z jednego adresu IP w krótkim czasie. Warto również zweryfikować daty modyfikacji plików .php na serwerze pod kątem nieautoryzowanych zmian.
Czy certyfikat SSL wystarczy, żeby sklep był bezpieczny?
Absolutnie nie. SSL chroni wyłącznie transmisję danych "w locie" - czyli zabezpiecza połączenie między przeglądarką klienta a Twoim serwerem. Certyfikat nie chroni przed dziurami w kodzie aplikacji, nieaktualnymi modułami ani słabymi hasłami w panelu administracyjnym.
Ile kosztuje naprawienie sklepu po udanym ataku?
Wszystko zależy od skali włamania. Samo usunięcie złośliwego kodu i przywrócenie witryny do działania to zazwyczaj od 4 do 16 godzin pracy doświadczonego programisty. Do tego musisz doliczyć czas na audyt bezpieczeństwa, analizę integralności bazy danych, rotację wszystkich kluczy API oraz haseł. Jeśli w wyniku ataku doszło do wycieku danych klientów, dochodzą poważne koszty prawne, obsługa zgłoszenia do UODO oraz potencjalne kary finansowe. Profesjonalna, stała opieka techniczna zapobiegająca takim kryzysom jest zawsze wielokrotnie tańsza.
