Dla kogo jest audyt techniczny
▶ 00:56Audyt 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:49Proces 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:26Zwykle 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:05Rdzeń 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:54Wię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:08W 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:43Szablon 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:12Bezpieczeń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:35W 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:46Raport 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:42Najczę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.



