E-COMMERCE / HANDEL DETALICZNY
Sklep e-commerce na PrestaShop — wykryte aktywne włamanie
Przegląd bezpieczeństwa działającego sklepu na PrestaShop 8.x okazał się analizą powłamaniową. Poza typowymi błędami konfiguracji wykryliśmy realne, aktywne zagrożenia: złośliwe skrypty (webshelle) wgrane na serwer, długotrwały backdoor, publicznie dostępną kopię pliku konfiguracyjnego z hasłami do bazy oraz ujawniony klucz API pozwalający odczytywać dane klientów i zamówienia. Najgroźniejsze elementy usunęliśmy natychmiast, resztę ujęliśmy w plan naprawczy z rekomendacją migracji.
DLACZEGO KLIENT SIĘ ZGŁOSIŁ
Klient zgłosił się z pozornie błahym problemem — sklep działał wolno. W rozmowie wyszło coś znacznie poważniejszego: sprzedaż od dłuższego czasu spadała, a biznes szedł coraz gorzej bez wyraźnego powodu. Przegląd wyjaśnił dlaczego. Ktoś — na bieżąco i po cichu — wykradał dane: adresy e-mail klientów oraz historię zamówień (kto, co i za ile kupił). To dokładnie te dane, na których konkurencja buduje przewagę: gotowa baza klientów z ich koszykiem zakupowym.
Klient oszacował straty na ~700 000 zł w ciągu dwóch lat — utracona sprzedaż i wartość systematycznie wyciekającej bazy klientów. Wyciek był cichy — nie było spektakularnego ataku, tylko powolne osłabianie biznesu.
METRYKA
| Branża | E-commerce / handel detaliczny |
| Platforma | PrestaShop 1.7 → 8.x (wykonany upgrade) |
| Zakres | Aplikacja · serwer · API · kopie zapasowe · poczta |
| Typ testu | Test penetracyjny + analiza powłamaniowa (porównanie kopii zapasowych) |
| Metodyka | OWASP WSTG v5 · PTES · NIST SP 800-115 · analiza integralności plików |
| Okres | przełom stycznia i lutego 2026 |
MACIERZ RYZYKA
Kluczowe ustalenia
- KRYTYCZNEAktywne backdoory (webshelle) wgrane na serwer
Dwa złośliwe skrypty PHP ukryte w plikach modułów. Analiza porównawcza kopii zapasowych dowiodła, że pojawiły się w konkretnym dniu (były nieobecne kilka dni wcześniej) — to potwierdzone, aktywne włamanie, a nie tylko teoretyczna podatność. Dawały atakującemu zdalne wykonywanie poleceń.
- KRYTYCZNEKlucz API sklepu umożliwiał odczyt danych klientów i zamówień
Ujawniony token dostępowy do webservice API pozwalał odpytać sklep o dane klientów, adresy i pełną historię zamówień (kto, co i za ile kupił). To najprawdopodobniej główny kanał cichego, ciągłego wycieku bazy klientów i zamówień — bez śladu w panelu sklepu.
- KRYTYCZNEHasła do bazy danych dostępne z internetu (kopia .bak)
Stara kopia pliku konfiguracyjnego z poświadczeniami do bazy, odłożona przy pracach deweloperskich i nieusunięta. Serwer oddawał ją jako czysty tekst (rozszerzenie .bak nie jest wykonywane jako PHP) — czytelna publicznie od ~2 lat.
- KRYTYCZNETrwały backdoor w module integracyjnym
Skrypt z dostępem do bazy danych i systemu plików, obecny na serwerze od jego powstania (~2 lata). Klasyczny mechanizm utrzymania dostępu (persistence) — niewidoczny w panelu sklepu.
- KRYTYCZNEPrzestarzała platforma (PrestaShop 1.7, koniec wsparcia) + podatne moduły
Sklep działał na PrestaShop 1.7 — wersji bez wsparcia bezpieczeństwa — z modułami z potwierdzonymi CVE. To fundament, na którym możliwe były pozostałe podatności; przesądza o konieczności modernizacji platformy.
- WYSOKIETryb debug włączony na produkcji
Aplikacja ujawniała wewnętrzne dane i ścieżki. Poprawione od ręki w trakcie analizy.
- WYSOKIELogi z danymi klientów częściowo dostępne z sieci
Log jednej z wtyczek (zawierający m.in. adresy IP klientów i kwoty zamówień) był dostępny publicznie, bez ochrony. Zabezpieczony regułą serwera; główne logi aplikacji były chronione (403).
- WYSOKIENiebezpieczne funkcje PHP odblokowane, brak izolacji
Funkcje takie jak exec/system/shell_exec były dostępne, a izolacja ścieżek (open_basedir) niewłączona — to dramatycznie zwiększa skutki wejścia atakującego przez webshell.
- ŚREDNIEKatalogi z prawami zapisu dla wszystkich (777)
Część katalogów na pliki/media była world-writable — możliwość wgrania lub podmiany plików.
- ŚREDNIEArchiwa ZIP modułów dostępne z sieci
Pozostawione paczki instalacyjne modułów można było pobrać z internetu — ułatwia analizę i atak na konkretne wersje.
- ŚREDNIEBrak nagłówków bezpieczeństwa i wyłączone zabezpieczenia sesji
Brak HSTS/CSP/X-Frame-Options; ciasteczka sesji bez flag httponly/secure — większa powierzchnia ataków XSS/clickjacking/przejęcia sesji.
Co było zrobione dobrze
- Włamanie ograniczone do uprawnień aplikacji (użytkownik serwera WWW) — atakujący nie mógł odczytać systemowego pliku haseł (/etc/shadow)
- Pliki i hasła systemowe nietknięte od założenia serwera
- Główne logi aplikacji oraz pliki konfiguracyjne chronione (HTTP 403)
- Polityka poczty DMARC w trybie p=reject
- Posiadane kopie zapasowe umożliwiły forensykę i ustalenie momentu włamania
Plan naprawczy
- Natychmiast: usunięcie obu webshelli i całego modułu z backdoorem, usunięcie kopii .bak z hasłami, unieważnienie i rotacja klucza API, wyłączenie trybu debug, zablokowanie dostępu do odsłoniętego logu
- 24–48h (zespół dev): rotacja haseł/kluczy, konfiguracja open_basedir i disable_functions, naprawa uprawnień katalogów (777 →), usunięcie archiwów ZIP, aktualizacja podatnych modułów, włączenie nagłówków i zabezpieczeń sesji
- Modernizacja: wykonaliśmy upgrade PrestaShop 1.7 → 8.x (powrót na wspieraną, regularnie łataną wersję); na czas prac ochrona ruchu przez CDN/WAF jako warstwa łagodząca
EFEKT
Przegląd ujawnił aktywne włamanie: webshelle, długotrwały backdoor, hasła do bazy dostępne publicznie od ~2 lat oraz klucz API otwierający dane klientów i zamówień. Najgroźniejsze elementy usunęliśmy natychmiast; resztę przekazaliśmy zespołowi deweloperskiemu z planem naprawczym i rekomendacją migracji. Włamanie było ograniczone do uprawnień aplikacji — system operacyjny i hasła systemowe pozostały nienaruszone, a moment włamania udało się ustalić dzięki analizie kopii zapasowych. W ramach naprawy wykonaliśmy też upgrade platformy z PrestaShop 1.7 do 8.x — sklep wrócił na wspieraną, regularnie łataną wersję.
PREWENCJA vs STRATA
Test penetracyjny za ~3 000 zł — z aktywnym, całorocznym monitoringiem w cenie — wykryłby ten wyciek na wczesnym etapie. Koszt prewencji był ponad 200× niższy niż szacowana strata.
Case zanonimizowany — pozbawiony nazwy, domeny, adresów IP i konkretnych technologii klienta. Publikacja zgodna z umową i Polityką prywatności.