Spistreści:
Do niedawna firmy podchodziły do bezpieczeństwa i jakości technicznej sklepu reaktywnie – naprawiano usterki dopiero wtedy, gdy coś przestawało działać. Dziś, w obliczu rosnących wymagań RODO, zaostrzających się standardów wyszukiwarki Google i coraz bardziej zorganizowanych ataków na sektor e-commerce, takie podejście jest zdecydowanie zbyt ryzykowne.
W Waynet każdego roku audytujemy dziesiątki sklepów opartych na PrestaShop, które trafiają pod nasze skrzydła. Zanim obejmiemy dany projekt stałą opieką technologiczną, zawsze przeprowadzamy rygorystyczny audyttechniczny. Z setek takich weryfikacji wyłaniają się bardzo wyraźne wzorce – te same błędy i luki bezpieczeństwa pozostawione przez poprzednie agencje występują w 70-80% nowo przejmowanych przez nas e-commerce’ów, niezależnie od branży i skali biznesu.
W tym artykule pokazujemy 5 najczęstszych z nich. Zobaczysz, jak manifestują się w codziennej pracy sklepu, jakie niosą ryzyko biznesowe, jak je wykryć oraz jak skutecznie rozwiązać. Wszystkie omówione przykłady pochodzą z realnych (choć zanonimizowanych) audytów Waynet.
Problem 1: Niezałatane podatności CVE w popularnych modułach komercyjnych
Jednym z najgroźniejszych problemów technicznych w e-commerce jest fakt, że na poziomie biznesowym do momentu incydentu nie daje on zazwyczaj żadnych objawów. Zjawisko to dotyczy modułów komercyjnych kupowanych w oficjalnym marketplace PrestaShop, takich jak systemy blogowe, formularze zapytań ofertowych czy rozbudowy karty produktu. Zdarza się, że posiadają one publicznie znane podatności (np. typu SQL injection) z oceną CVSS 9.8, co oznacza najwyższy poziom krytyczności. Co gorsza, atak nie wymaga logowania – hakerowi wystarczy wywołanie określonego adresu URL frontu sklepu.
Podczas jednego z audytów w Waynet znaleźliśmy w pojedynczym sklepie aż 3 takie podatności w modułach od trzech różnych producentów. Wszystkie luki były znane od ponad 2 lat. Producenci wydali łatki, ale właściciel sklepu o tym nie wiedział, ponieważ standardowa instalacja PrestaShop nie posiada centralnego mechanizmu informowania o aktualizacjach zewnętrznych wtyczek. Zignorowanie tego zagrożenia pociąga za sobą gigantyczne ryzyko:
- Wyciek bazy klientów i naruszenie art. 32–33 RODO (obowiązek zgłoszenia incydentu w 72 godziny).
- Możliwość nałożenia kary przez UODO wynoszącej do 4% rocznego obrotu.
- Ogromne koszty PR i utrata zaufania konsumentów.
- W przypadku e-commerce B2B – realna utrata kluczowych kontraktów.
Aby wykryć to zagrożenie, należy porównać wersje każdego zainstalowanego modułu z globalną bazą podatności NVD (National Vulnerability Database). Manualnie zajmuje to wiele godzin przy kilkudziesięciu modułach, jednak nasz audyt całkowicie to automatyzuje. Rozwiązaniem jest aktualizacja modułu do najnowszej wersji lub jego dezaktywacja i znalezienie bezpiecznej alternatywy. W ten sposób zamykasz konkretną furtkę dla atakującego, a czas wdrożenia poprawki to zazwyczaj 1-3 dni robocze na moduł.
Problem 2: Wyciek dokumentów klientów B2B przez moduły bez kontroli dostępu
Ten problem również rozwija się w ukryciu. Właściciel sklepu zazwyczaj dowiaduje się o nim dopiero wtedy, gdy zirytowany klient lub konkurencja zgłosi publiczną dostępność wrażliwych dokumentów. Wiele platform B2B używa modułów, które pozwalają klientom wgrywać pliki niezbędne do współpracy. Niestety, część z nich posiada endpoint pobierania, który w ogóle nie sprawdza, czy użytkownik jest zalogowany ani czy jest właścicielem danego dokumentu. Każdy anonimowy internauta, iterując po prostych identyfikatorach URL, może pobrać dokumenty wszystkich klientów sklepu.
W autentycznym e-commerce B2B audytowanym przez Waynet w taki sposób wyciekły:
- numery NIP kilkuset firm klienckich,
- pełnomocnictwa upoważniające do zakupów,
- wewnętrzne certyfikaty firmowe,
- skanowane dowody osobiste dyrektorów i pracowników.
Skutki są katastrofalne. Brak adekwatnych zabezpieczeń (RODO art. 32 i 33) naraża firmę na administracyjne kary sięgające do 20 mln euro lub 4% rocznego obrotu. W świecie B2B oznacza to również lawinę wymówień umów oraz pozwów cywilnych od poszkodowanych firm. Co ważne, prowadząc sklep, zazwyczaj nie jesteś w stanie samodzielnie sprawdzić warstwy autoryzacji – wymaga to weryfikacji kodu przez dewelopera. Audyt techniczny drobiazgowo prześwietla moduły uploadu, modyfikacje routingu i override kontrolerów. Jeśli oprogramowanie nie jest zaszyfrowane, dodanie warstwy autoryzacji zamyka się zwykle w 1-2 dniach roboczych.
Problem 3: Override w rdzeniu, których nikt w firmie nie pamięta
Jeżeli aktualizacje Twojego sklepu przysłowiowo „wybuchają”, każda migracja kończy się tygodniami wyczerpującego debugowania, a wycena przejścia na nowszą wersję platformy przypomina wróżenie z fusów – najprawdopodobniej masz problem z modyfikacjami w rdzeniu. Override to nadpisanie oryginalnego pliku z rdzenia PrestaShopa własną wersją. W zdrowym systemie powinno być ich zaledwie kilka, jednak w typowym sklepie z długą historią jest ich kilkadziesiąt.
W jednym z naszych audytów wykryliśmy 22 grupy nadpisań rdzenia, co dało łącznie ponad 4 000 linii kodu. Wśród nich znajdował się 587-liniowy duplikat potężnej metody walidacji zamówień, którego jedyną funkcjonalną zmianą była… spacja dodana w tłumaczeniu maila potwierdzającego zakup! Takie zapomniane łatki blokują płynne aktualizacje bezpieczeństwa (każda łatka wymaga ręcznego łączenia kodu) oraz opóźniają niezbędną migrację do PrestaShop 9.x. Zwiększają też koszty utrzymania, budując ogromny dług techniczny.
Nasz audyt mapuje wszystkie override, docieka ich realnej funkcji biznesowej i szacuje ryzyko regresji. Dla każdej modyfikacji podejmujemy decyzję o usunięciu (najczęstszy scenariusz), refaktoryzacji lub pozostawieniu. Proces porządkowania zajmuje od 2 do 4 tygodni, ale inwestycja ta zwraca się w całości przy pierwszej migracji, która nagle zamiast trzech miesięcy, trwa zaledwie trzy tygodnie.
Problem 4: Pliki diagnostyczne wystawione publicznie bez autoryzacji
To bardzo powszechny błąd, który nie daje żadnych objawów dla administratora, za to jest kluczowym, pierwszym krokiem atakującego przed właściwym włamaniem. Mowa o plikach typu phpinfo.php pozostawionych w katalogu sklepu pod publicznym adresem URL. Ujawniają one hakerowi pełną konfigurację serwera PHP, ścieżki systemowe, listę rozszerzeń, zmienne środowiskowe, a nierzadko również hasła do bazy danych.
Taka luka to najczęściej efekt rutynowej praktyki deweloperskiej: programista uruchamia skrypt diagnostyczny, by sprawdzić konfigurację, po czym zapomina go usunąć. Trafiamy na nie w blisko 25% weryfikowanych sklepów. Ułatwia to atakującemu zadanie, gdyż dokładnie wie, jakimi narzędziami uderzyć, by uzyskać bezpośredni dostęp do bazy. Skutkiem jest włamanie, wyciek danych oraz gigantyczny kryzys komunikacyjno-prawny. Audyt sprawnie skanuje root katalogu i najczęstsze lokalizacje pod kątem pozostałości po deweloperach. Choć usunięcie intruza trwa minutę, kluczowe jest sprawdzenie w logach, czy nikt go wcześniej nie odwiedził. Jeśli tak – wymagana jest pełna rotacja danych dostępowych.
Problem 5: Wiele równolegle aktywnych kluczy API z pełnym dostępem
Częstą bolączką dojrzałych biznesów e-commerce jest chaos w integracjach. Nikt w firmie nie wie, kto i kiedy podłączył kolejny integrator systemowy, a panel sklepu pęka w szwach od aktywnych kluczy API, z których większość nie była używana od miesięcy. Klucz API to w uproszczeniu plik dostępu, który ma pełne uprawnienia do konkretnych zasobów: klientów, pracowników, cenników i zamówień.
W realnym sklepie audytowanym przez naszą ekipę wykryliśmy trzy równolegle aktywne klucze do trzech konkurencyjnych integratorów zamówień, z których każdy miał dostęp do blisko 70 wrażliwych zasobów. Jeśli sklep używa tylko jednego z nich, pozostałe stanowią szeroko otwarte drzwi dla cyberprzestępców. Wyciek klucza (np. z byłem agencji IT lub od zwalnianego pracownika) daje hakerom pełen dostęp do historii zamówień. Rozszerza to tzw. powierzchnię ataku i całkowicie niszczy audytowalność zdarzeń. Rozwiązaniem jest wyłączenie nieużywanych kluczy (co zazwyczaj dotyczy 50-70% wszystkich) oraz ograniczenie uprawnień reszty zgodnie z zasadą „najmniejszych uprawnień”. Wdrożenie takich prewencyjnych zasad zajmuje zaledwie 1 dzień roboczy, a same tokeny powinny być regularnie rotowane przynajmniej co pół roku.
Co łączy te 5 problemów?
Mimo że wynikają z różnych technologii, wszystkie błędy mają wspólny mianownik:
- Istnieją w systemie całkowicie cicho. Żaden z nich nie spowoduje, że klient poskarży się na wolne ładowanie sklepu. Są niewidoczne, dopóki nie wydarzy się coś tragicznego w skutkach.
- Wykrywa je wyłącznie systematyczny audyt. Problemów tych nie wskaże Lighthouse, PageSpeed Insights ani standardowy skaner antywirusowy u hostingodawcy. Wymagają żmudnej, manualnej analizy kodu przeprowadzonej przez eksperta.
- Są ekstremalnie drogie w naprawie po incydencie. Prewencyjne skasowanie pliku konfiguracyjnego to kwestia minuty. Po włamaniu czekają Cię dni audytu śledczego, zawiadomienia do urzędów i procesy cywilne. W efekcie firmy działające reaktywnie wydają rocznie od 5 do 10 razy więcej na infrastrukturę niż te, które dbają o prewencję.
Sprawdź, czy Twój sklep ma któryś z tych problemów
Statystycznie Twoja platforma posiada w tym momencie od jednego do trzech opisanych wyżej problemów, niezależnie od tego, czy zdajesz sobie z tego sprawę. W ramach bezpłatnego audytu technicznego Waynet sprawdzimy, które usterki dotyczą Twojego sklepu. Wskażemy konkretne ścieżki plików oraz nazwy podatnych modułów i podpowiemy, od czego zacząć naprawę. Audyt zamykamy w 5 dni od zapisu, a bezpłatny 28-stronicowy raport PDF zostaje u Ciebie na zawsze – bez względu na to, czy zdecydujesz się na współpracę z naszą agencją.
