Start / YouTube / Odcinek
Odcinek Dr-Ecommerce · 12:41

Audyt techniczny sklepu PrestaShop: co sprawdzamy i co znajdujemy

Czy mój sklep jest bezpieczny? Czy mogę go zaktualizować? Dlaczego tak wolno się ładuje? Jerzy Żanowski pokazuje, jak wygląda techniczna analiza sklepu na PrestaShop: co sprawdza się w rdzeniu, modułach i bazie danych oraz jakie problemy wychodzą w prawdziwych audytach.

Prowadzący: Jerzy Żanowski
Audyt techniczny sklepu PrestaShop: co sprawdzamy i co znajdujemy
W skrócie

Najważniejsze wnioski z odcinka

  • Audyt ma 5 kroków i trwa około 5 dni roboczych: zgłoszenie, rozmowa online na 20–30 minut, dostępy tylko do odczytu, analiza na kopii sklepu i omówienie wyników.
  • Wystarczy dostęp SFTP do odczytu i kopia bazy albo dostęp do bazy w trybie read only. Na życzenie najpierw podpisuje się NDA, a na sklepie produkcyjnym nic się nie zmienia.
  • Rdzeń: wersja PrestaShop, ścieżka aktualizacji, ręczne zmiany w plikach i znane luki CVE. W jednym sklepie było 15 niezałatanych, publicznie opisanych podatności.
  • Moduły: dostawca, zgodność wersji w bazie i na serwerze, kod zaszyfrowany IonCube, dublujące się i porzucone dodatki. W jednym sklepie sklasyfikowano 137 modułów.
  • Największe niespodzianki kryją się w modułach dedykowanych: surowy SQL z pominięciem mechanizmów PrestaShop, dane wpisane na sztywno w kod i brak procedury aktualizacji.
  • Przykłady z audytów: wstrzyknięcie SQL bez logowania przy łatkach czekających ponad 2 lata, moduł B2B wydający cudze dokumenty firmowe i publiczny plik phpinfo.
  • Raport ma około 30 stron: streszczenie z top 5 problemów i rekomendacji, oceny 1–10 w 6 kategoriach, mapę modułów, numery CVE i plan na 30, 90 i 365 dni.

Dla kogo jest audyt techniczny

▶ 00:56

Audyt jest dla każdego, kto prowadzi sklep na PrestaShop i choć raz zadał sobie jedno z pytań: czy mój sklep jest bezpieczny, czy mogę go w ogóle zaktualizować i dlaczego tak wolno się ładuje.

Proces krok po kroku

▶ 01:49

Proces ma 5 kroków i zajmuje około 5 dni roboczych od zgłoszenia do gotowego raportu. Podajesz adres sklepu, wersję PrestaShop i dane kontaktowe, a odpowiedź przychodzi w ciągu 24 godzin roboczych.

Potem jest rozmowa online na 20–30 minut: jak przebiega audyt i jakie dostępy będą potrzebne. Po analizie kolejne spotkanie, na którym omawia się konkretnie, co naprawić najpierw, co zaplanować na średni termin, a co odłożyć.

NDA, dostępy i praca na kopii sklepu

▶ 02:26

Zwykle wystarczy dostęp SFTP wyłącznie do odczytu oraz kopia bazy danych albo dostęp do bazy w trybie read only. Jeśli chcesz dodatkowego komfortu, przed udostępnieniem czegokolwiek podpisuje się umowę NDA.

Mapowana jest cała technologia sklepu: moduły, nadpisania rdzenia, szablon, baza danych, integracje zewnętrzne i bezpieczeństwo. Na sklepie produkcyjnym nic się w tym czasie nie zmienia, bo praca odbywa się wyłącznie na kopii.

Rdzeń PrestaShop i podatności CVE

▶ 04:05

Rdzeń to główny silnik, na którym opiera się cała reszta. Sprawdzana jest wersja PrestaShop, ścieżka aktualizacji i znane luki bezpieczeństwa, czyli CVE: oficjalnie potwierdzone i publicznie opisane podatności, których nikt nie załatał. Do tego to, czy ktoś ręcznie zmieniał pliki rdzenia. Przestarzały albo przerobiony fundament sprawia, że każda aktualizacja staje się ryzykowna.

Przykład z audytu: sklep z 15 niezałatanymi podatnościami. Wszystkie były opisane w internecie, więc mógł o nich przeczytać każdy, także ktoś, kto chciał ten sklep zaatakować.

Moduły: co działa, co się dubluje, co jest martwe

▶ 04:54

Większość sklepów na PrestaShop ma dziesiątki, a czasem ponad 100 modułów. Audyt sprawdza każdy: kto jest dostawcą, czy wersja w bazie danych zgadza się z plikami na serwerze, czy są moduły zaszyfrowane IonCube, których kodu nie przeczyta nawet właściciel sklepu, i czy są takie, o których nikt w firmie nie pamięta.

Im starszy sklep i im częściej zmieniali się e-commerce managerowie, tym dłuższa lista porzuconych dodatków. W jednym sklepie sklasyfikowano 137 modułów. Ważne jest, co naprawdę działa na co dzień, gdzie dwa moduły robią to samo i co od dawna jest martwe, a wciąż zajmuje miejsce i generuje ryzyko.

Moduły dedykowane: surowy SQL i hardkody

▶ 06:08

W modułach pisanych na zamówienie najczęściej kryją się największe niespodzianki. Audyt sprawdza, czy w kodzie jest surowy SQL, czyli zapytania do bazy pisane ręcznie z pominięciem standardowych, bezpiecznych mechanizmów PrestaShop.

Sprawdzane są też hardkody, czyli dane zaszyte na sztywno w kodzie zamiast w konfiguracji, oraz to, czy w ogóle istnieje procedura aktualizacji tych modułów.

Szablon i ręczna edycja na serwerze

▶ 07:43

Szablon to część, którą widzą klienci. Audyt sprawdza, czy proces budowania szablonu jest uporządkowany, czy ktoś ręcznie edytował pliki bezpośrednio na serwerze produkcyjnym i czy widoki modułów nadpisano tak, że utrudnia to przyszłe aktualizacje. Szczególnie ważne jest to przy kilku sklepach na jednej instancji, czyli w popularnym multistore.

Bezpieczeństwo: przykłady z audytów

▶ 08:12

Bezpieczeństwo to zwykle najbardziej alarmująca część audytu: CVE w rdzeniu, podatności w modułach komercyjnych, potencjalne wycieki danych i zgodność z RODO.

Pierwszy przykład: potwierdzone wstrzyknięcia kodu SQL w aktywnych, płatnych modułach. Atakujący przemyca złośliwą komendę do bazy przez formularz albo adres strony. Tu nie trzeba było nawet się logować, wystarczył odpowiedni adres URL na froncie, a łatki od producenta czekały nieużyte ponad 2 lata.

Drugi przykład: w sklepie B2B moduł do przesyłania dokumentów firmowych (numery NIP, pełnomocnictwa, certyfikaty) nie sprawdzał, czy pobierający jest zalogowany i czy to jego dokument. Można było pobrać cudze poufne pliki. Do tego publicznie dostępny plik phpinfo, który ujawnia konfigurację serwera, ścieżki, zmienne środowiskowe, a czasem dane dostępowe do bazy. To zwykle pierwszy krok osoby planującej włamanie.

Baza danych: tabele widma i brakujące indeksy

▶ 09:35

W bazie sprawdzane jest m.in. kodowanie znaków i tak zwane tabele widma, które zostały po dawno wyłączonych integracjach.

Duży wpływ na szybkość mają brakujące indeksy. Indeks działa jak skorowidz na końcu książki: bez niego baza musi przeczytać wszystko od początku do końca, żeby znaleźć jedną informację. To potrafi mocno spowolnić cały sklep.

Co jest w raporcie

▶ 10:46

Raport w PDF ma około 30 stron. Na pierwszej stronie jest streszczenie zarządcze z top 5 problemów i top 5 rekomendacji, dla kogoś, kto nie ma czasu czytać całości.

Dalej: oceny od 1 do 10 w 6 kategoriach z uzasadnieniem, pełna mapa modułów, lista nadpisań rdzenia z oceną ryzyka przy migracji, analiza bezpieczeństwa z numerami CVE, wąskie gardła bazy, szybkie wygrane wydajnościowe i plan działania na 30, 90 i 365 dni. Do tego 30 minut rozmowy, na której omawia się wyniki na żywo.

Dlaczego audyt jest bezpłatny

▶ 11:42

Najczęstsze pytanie: gdzie jest haczyk? Jerzy odpowiada, że go nie ma. Audyt to sposób, żeby zobaczyć prawdziwy stan sklepu, zanim zaproponuje się jakąkolwiek współpracę, albo uczciwie powiedzieć, że nie jest się najlepszym partnerem dla projektu.

Raport zostaje u właściciela sklepu niezależnie od decyzji o dalszej współpracy, bez umowy i bez presji sprzedażowej. Zgłoszenia przyjmowane są przez formularz na audyt.waynet.pl.

FAQ

Pytania i odpowiedzi z odcinka

Ile trwa audyt techniczny sklepu PrestaShop?

Około 5 dni roboczych od zgłoszenia do gotowego raportu. Proces ma 5 kroków: zgłoszenie, rozmowa online, dostępy, analiza na kopii sklepu i omówienie wyników.

Jakich dostępów wymaga audyt PrestaShop?

Zwykle dostępu SFTP tylko do odczytu oraz kopii bazy danych albo dostępu do bazy w trybie read only. Na życzenie najpierw podpisuje się NDA, a analiza odbywa się na kopii, bez zmian w sklepie produkcyjnym.

Co sprawdza audyt techniczny sklepu na PrestaShop?

Rdzeń (wersja, ścieżka aktualizacji, ręczne zmiany, podatności CVE), wszystkie moduły, moduły dedykowane (surowy SQL, hardkody), szablon, bezpieczeństwo i RODO oraz bazę danych, w tym brakujące indeksy.

Co to jest CVE?

To oficjalnie potwierdzona i publicznie opisana podatność w oprogramowaniu. Jeśli nie jest załatana, każdy, także atakujący, może przeczytać, jak jej użyć.

Co zawiera raport z audytu PrestaShop?

Około 30 stron: streszczenie z top 5 problemów i rekomendacji, oceny 1–10 w 6 kategoriach, mapę modułów, nadpisania rdzenia z oceną ryzyka, analizę bezpieczeństwa z numerami CVE, wąskie gardła bazy i plan działania na 30, 90 i 365 dni.

Project Management

Nie wiesz, w jakim stanie jest Twój sklep?

Prowadzę wdrożenia, migracje i sklepy B2B po stronie klienta jako project manager na godziny. Pakiety od 10 h w miesiącu, start w 48 h do tygodnia.

Sprawdź, jak pracuję
Pełna transkrypcja odcinka

Transkrypcja z automatycznych napisów YouTube. Mogą się w niej zdarzyć błędy, w razie wątpliwości liczy się nagranie.

Bezpłatny audyt techniczny sklepu PrestaShop

00:56
TO JEST TO BEZPŁATNA TECHNICZNA ANALIZA TWOJEGO SKLEPU NA PRESTASHOP dla kogo jest ten audyt szczerze mówiąc dla każdego kto prowadzi sklep na prestashop i choć raz zadał sobie 1 z tych pytań czy mój sklep jest bezpieczny czy mogę w ogóle za go zaktualizować albo na przykład dlaczego on tak wolno się ładuje

Jak wygląda proces audytu e-commerce krok po kroku?

01:49
Jak wygląda ten proces audytu krok Po kroku ten proces składa się z 5 kroków i zajmuje około 5 dni roboczych OD zgłoszenia się do mnie do gotowego raportu który ci zwracam podajesz adres sklepu podajesz wersję prestashop i Dane kontaktowe a ja odpowiadam na to na to zapytanie w ciągu 24h roboczych które zajmuje Nam 20 30min i robimy je online omawiamy Jak przebiega cały ten audit ustalamy jakich dostępów OD ciebie będziemy potrzebować

Umowa NDA, dostępy i bezpieczne środowisko testowe

02:35
zwykle to dostęp sftp wyłącznie do odczytu plus kopia bazy danych albo dostęp do bazy w trybie read only jeśli chcesz mieć dodatkowy komfort podpisujemy z tobą umowę NDA zanim cokolwiek Nam udostępnisz mapujemy technologię sklepu wszystkie moduły nadpisania w rdzeniu systemu sprawdzamy szablon sprawdzamy bazy danych integracji zewnętrznej bezpieczeństwo i to jest bardzo ważne Nic w tym czasie nie zmieniamy w twoim sklepie produkcyjnym dlatego że pracujemy wyłącznie na jego kopi to zajmuje Nam 30:45 min wówczas z tobą omawiamy wprost i konkretnie co naprawić w 1. kolejności

03:21
co można zaplanować na średni termin a co odłożyć na dłuższą perspektywę z oceną w 6 kategoriach z listą top 5 problemów top 5 rekomendacji i planem działania na najbliższe 30 90 i 365 dni a teraz najważniejsza część tego odcinka czyli co dokładnie sprawdzamy w tym audycie bo samo słowo audyt techniczny brzmi bardzo ogólnie prawda dlatego chcę ci dokładnie pokazać co to jest co to jest ta konkretna dziewięcioobszarowa analiza więc polecimy teraz punkt Po punkcie obszar Po obszarze tutaj Jak wiem rdzeń to jest fundament sklepu

Weryfikacja rdzenia PrestaShop i podatności CVE

04:07
czyli główny silnik na którym wszystko inne się opiera sprawdzamy jaką wersję presty posiadasz jaka jest ścieżka do aktualizacji i czy są znane luki bezpieczeństwa fachowo nazywane cve czyli oficjalnie potwierdzone i publicznie opisane podatności których nikt nie załatał sprawdzamy też czy ktoś ręcznie majstrował przy plikach rdzenia bo jeśli fundament jest przestarzały albo ręcznie zmieniony to każda kolejna aktualizacja staje się ryzykowna konkretny przykład z 1 z naszych audytów sklep który miał 15 niezałatanych podatności 15 publicznie znanych opisanych w internecie dziur bezpieczeństwa o których każdy mógł przeczytać łącznie z osobą która chciałaby zaatakować ten sklep

Analiza zainstalowanych modułów sklepu internetowego

04:55
większość sklepów na presta ma dziesiątki a czasem nawet ponad 100 zainstalowanych modułów to takie klocki z których te sklepy się składają Po prostu tak działa presta no tutaj myślę że to jest dla wszystkich wiadome my sprawdzamy je wszystkie kto jest dostawcą każdego modułu czy wersja zapisana w bazie danych zgadza się z wersją plików na serwerze czy są moduły zaszyfrowane tak zwanym ion cube'm czyli kod którego zawartości nie można przeczytać nie może przeczytać nawet właściciel sklepu i oraz czy są moduły o których nikt w firmie już nie pamięta kto je w ogóle zainstalował i Po co i to jest dość ciekawe bo im starszy sklep tym i też częściej zmieniający się e-commerce menadżerowie tym lista takich właśnie modułów troszeczkę porzuconych będzie coraz dłuższa

05:40
i w 1 ze sklepów które analizowaliśmy sklasyfikowaliśmy 137 modułów w 1 sklepie tutaj sprawdzamy czy w twoim sklepie faktycznie co tak naprawdę działa na co dzień gdzie funkcje się dublują bo na przykład 2 różne moduły robią często to samo i które elementy są OD dawna martwe ale wciąż zajmują miejsce w systemie i mogą generować niepotrzebne ryzyko czyli tak zwane customy i to tutaj najczęściej kryją się największe niespodzianki sprawdzamy czy w kodzie jest surowy SQL wklejony bezpośrednio do modułu czyli zapytania do bazy danych pisane ręcznie z pominięciem standardowych bezpiecznych mechanizmów prestashop sprawdzamy też tak zwane hard kody

Błędy w modułach dedykowanych i surowy kod SQL

06:26
czyli Dane zaszyty na sztywno w kodzie zamiast w konfiguracji no i sprawdzamy czy w ogóle istnieje jakiekolwiek procedura aktualizacji tych customowych modułów

Audyt szablonów i ryzyko ręcznej edycji plików na serwerze

07:43
ta którą widzą twoi klienci sprawdzamy czy proces budowania szablonu jest uporządkowany czy ktoś ręcznie edytował pliki bezpośrednio na serwerze produkcyjnym co jest bardzo oczywiście ryzykowe i czy widoki poszczególnych modułów zostały nadpisane w sposób który utrudnia przyszłe aktualizacje zwłaszcza jeśli masz kilka sklepów działających na 1 instancji czyli ten popularny multistore to zazwyczaj najbardziej alarmująca część całego sklepu 3 sprawdzamy cve w rdzeniu podatności w modułach komercyjnych potencjalne wycieki danych i zgodność z rodo 2 przykłady które się wydarzyły w 1 z audytów 01:03 potwierdzone wstrzyknięcia kodu SQL

Przykłady krytycznych luk bezpieczeństwa i wycieków danych

08:31
w aktywnych płatnych budłach wstrzyknięcie SQL w wielkim skrócie to taka sytuacja w której ktoś przemyca jakąś złośliwą komendę do bazy danych przez zwykły formularz albo adres strony w tym przypadku atak nie wymagał nawet zalogowania się do sklepu wystarczyło wywołać odpowiedni adres url na froncie łatki OD producenta modułu czekały nieużyte OD ponad 2 lat i 2. przykład w sklepie działającym w modelu bitubi moduł do przesyłania dokumentów firmowych numery nip pełnomocnictwa certyfikaty klientów w ogóle nie sprawdzał czy osoba pobierająca plik jest zalogowana i czy to w ogóle jest jej dokument mógł pobrać cudze poufne dokumenty no jeszcze 1 znalezisko publicznie dostępny plik PHP

09:16
info w katalogu sklepu to plik diagnostyczny który ujawnia pełną konfigurację serwera ścieżki systemowe zbiedne środowiskowe czasem nawet Dane dostępowe do bazy danych to zazwyczaj 1. krok jaki wykonuje osoba EE planująca włamanie do sklepu kodowanie znaków tak zwane tabelę widma które zostały Po dawno wyłączonych integracjach i nikt ich nie usunął oraz też brakujące indeksy indeks w bazie indeks w bazie danych działa troszkę Jak indeks na końcu książki jego brak sprawia że baza musi przeczytać wszystko OD początku do końca żeby znaleźć 1 informację a Po prostu samo z siebie mocno to wszystko może spowolnić działanie całego sklepu

Co dokładnie zawiera 30-stronicowy raport z audytu?

10:47
trzymasz raport w pdf-ie to jest około 30 stron w środku znajdziesz streszczenie zarządcze z top 5 problemami i top 5 rekomendacjami na samej 1. stronie żebyś nie musiał czytać wszystkiego jeśli nie masz na to czasu oceny OD 1:10 w 6 kategoriach z uzasadnieniem każdej z nich pełną mapę wszystkich modułów listę nadpisań rdzenia z oceną ryzyka przy migracji szczegółową analizę bezpieczeństwa z konkretnymi numerami cve wąskie gardła bazy danych szybkie yy wygrane wydajnościowe i road mapy na kolejnych 30 90 i 365 dni czyli konkretny uporządkowany plan działania a nieluźne sugestie które rzucamy na koniec spotkania

11:35
do tego wszystkiego 30min rozmowy na której omawiamy to razem na żywo i pytanie które dostaję chyba najczęściej dlaczego jest to darmowe no i gdzie tutaj jest haczyk no i odpowiedź jest prosta nie ma haczyka to dla NAS sposób żeby zobaczyć w jakim stanie naprawdę jest twój sklep zanim w ogóle zaproponujemy jakąkolwiek dalszą współpracę albo żeby uczciwie powiedzieć że nie jesteśmy najlepszym dopasowaniem dla twojego projektu raport zostaje u ciebie niezależnie OD tego czy zdecydujesz się później z Nami współpracować bez podpisywania umowy bez presji sprzedażowej czy prowadzisz sklep na prestashop i chociaż przez chwilę zastanawiałeś się co się dzieje pod jego maską tak odezwij się do mnie na mój adres mailowy jerzy.zanowski@waynet.pl pl albo wypełniając formularz na stronie audyt.waynet.pl

Dlaczego audyt PrestaShop jest darmowy i nie ma haczyków?

12:21
pl tak i umów się ze mną na rozmowę a zobaczysz szerszą perspektywę dotyczącą twojego sklepu pozdrawiam jeśli ten materiał był dla ciebie przydatny zostaw łapkę w górę i zasubskrybuj kanał dr e-commerce commerce aby otrzymywać w przyszłości więcej takich konkretów dzisiaj ci już dziękuję i do zobaczenia w kolejnym materiale