Jak samodzielnie zaudytować sklep PrestaShop — darmowy moduł Security Scan

Dwa sposoby na sprawdzenie sklepu

Jeśli chcesz mieć szybki obraz sytuacji w kilka sekund, użyj naszego publicznego Security Scannera: podajesz adres URL sklepu, a on pasywnie rozpoznaje wersje PrestaShop i PHP, sprawdza, czy ta wersja jest publicznie widoczna lub ma status end-of-life, i analizuje nagłówki bezpieczeństwa HTTPS — bez instalacji i bez konfiguracji. Odczytuje wyłącznie to, co i tak widzi każdy odwiedzający.

Na tym też kończą się jego możliwości. Publiczny test nie powie, jakie wersje modułów faktycznie masz zainstalowane, jakie są uprawnienia Twoich plików, czy włączony jest tryb debugowania ani czy w katalogu głównym serwisu leży kopia zapasowa .sql — a to właśnie ta ostatnia kategoria odpowiada za większość włamań do sklepów PrestaShop. Do tego służy darmowy moduł Security Scan: skanuje sklep od środka, gdzie zgoda jest oczywista, bo to przecież Twój sklep. Ten poradnik pokazuje, jak uruchomić skan, jak czytać raport i — z użyciem prawdziwych poleceń — jak naprawić to, co znajdzie. Jako pogłębione kompendium hartowania dalej idzie nasza towarzysząca lista kontrolna hartowania bezpieczeństwa PrestaShop.

Co sprawdza skan lokalny

Raport jest pogrupowany tematycznie — najpierw kontrole potwierdzone (wersje, odsłonięte pliki), potem heurystyczne (malware i kod), które są wyraźnie oznaczone. Każde znalezisko mówi, co wykryto, dlaczego to istotne i jak to naprawić.

Grupy dotyczące malware i kodu są heurystyczne celowo — to trafne przypuszczenia, które od czasu do czasu oznaczą coś niegroźnego. Wolimy pokazać Ci fałszywy alarm, który odrzucisz w dziesięć sekund, niż po cichu przeoczyć web shella.

Każde znalezisko można zweryfikować. Każde dopasowanie wersji i CVE prowadzi bezpośrednio do oficjalnego biuletynu — rekordu CVE lub GitHub Security Advisory producenta — i ma przypisany poziom pewności, więc każde oznaczenie możesz sprawdzić samodzielnie, zamiast wierzyć nam na słowo. Tam, gdzie skaner może coś jedynie wywnioskować albo nie jest w stanie potwierdzić ustawienia z zewnątrz, mówi to wprost i przyznaje niską ocenę pewności. Został zbudowany tak, by być rzetelnym, a nie alarmistycznym.

Jak uruchomić skan

Zainstaluj i włącz darmowy moduł Security Scan, następnie otwórz Konfiguruj → Security Scan → Scan & Report i kliknij Run scan now. Typowy skan trwa kilka sekund. Kontrole jedynie odczytują pliki, konfigurację i bazę danych sklepu oraz Twoje własne publiczne adresy URL; moduł zapisuje wyłącznie własny wpis w historii skanów, więc nigdy nie modyfikuje plików sklepu, ustawień, produktów, zamówień ani klientów — jest bezpieczny na działającym sklepie.

Wolisz wiersz poleceń albo chcesz to zautomatyzować? Ten sam lokalny skan możesz wywołać ze zbootstrapowanego kontekstu PrestaShop (zabezpieczenie nie pozwoli uruchomić go przez WWW, jeśli zostawisz plik na serwerze):

<?php
// scan-now.php — run from the CLI only; delete the file if you place it in the shop root
if (PHP_SAPI !== 'cli') {
    http_response_code(403);
    exit;
}

require __DIR__ . '/config/config.inc.php';
require __DIR__ . '/modules/mprsecurityscan/vendor/autoload.php';

$run = \MPRSecurityScan\Service\ScanRunner::runAndStore('manual');
printf("Score %d/100 (grade %s) — %d issues\n",
    $run['result']['score'], $run['result']['grade'], $run['result']['problem_count']);

Jak czytać swój wynik

Otrzymujesz jedną liczbę w skali do 100 oraz ocenę literową. Wynik startuje od 100 i traci punkty za każdy rzeczywisty problem, ważony jego powagą — problem krytyczny kosztuje znacznie więcej niż drobny. Zaliczone kontrole też są pokazywane, więc widzisz, co faktycznie zostało zweryfikowane.

• Krytyczne −30 za każde — możliwe do wykorzystania już teraz albo potwierdzona ekspozycja. Napraw jeszcze dziś.
• Wysokie −15 — poważne; napraw w tym tygodniu.
• Średnie −7 — istotne braki w hartowaniu lub higienie.
• Niskie −3 — drobne usprawnienia.

To wszystko składa się na ocenę — A 90+, B 75+, C 60+, D 40+, F poniżej 40. Traktuj wynik jako narzędzie do ustalania priorytetów, a nie gwarancję: wysoki wynik oznacza, że skaner nie znalazł żadnych znanych problemów w tym, co jest w stanie zobaczyć.

Przykład z życia: odsłonięty katalog .git

To jedno z najczęstszych — i najgroźniejszych — znalezisk. Jeśli wdrażasz sklep przez git clone lub git pull bezpośrednio do katalogu głównego serwisu, cały katalog .git (z pełną historią źródeł i wszystkimi sekretami, jakie kiedykolwiek trafiły do commitów) może być możliwy do pobrania. Skaner potwierdza to, faktycznie odpytując /.git/HEAD przez HTTP i sprawdzając, czy odpowiedź wygląda jak metadane systemu kontroli wersji.

Krytyczne — metadane VCS są publicznie osiągalne. Skaner potwierdził, że /.git/HEAD zwraca metadane VCS przez HTTP.

Napraw to w dwóch krokach. Najpierw, z katalogu głównego sklepu, zrób kopię zapasową metadanych i usuń je (zabezpieczenia dopilnują, by nic nie zostało skasowane, dopóki kopia się nie powiedzie):

# run from your shop root
set -eu

paths=()
[ -d .git ] && paths+=(.git)
[ -d .svn ] && paths+=(.svn)

if [ "${#paths[@]}" -gt 0 ]; then
  tar czf "$HOME/vcs-metadata-backup-$(date +%F-%H%M%S).tgz" "${paths[@]}"
  rm -rf "${paths[@]}"
fi

Następnie upewnij się, że serwer WWW odmawia dostępu do katalogów z kropką, nawet gdyby któryś pojawił się ponownie. Apache (.htaccess lub vhost) — ta reguła blokuje pliki z kropką oraz ścieżki katalogów z kropką, takie jak /.git/HEAD, zachowując przy tym /.well-known/:

<FilesMatch "^\.">
  Require all denied
</FilesMatch>

RedirectMatch 404 "(^|/)\.(?!well-known(?:/|$))"

Albo nginx:

location ^~ /.well-known/ {
    try_files $uri =404;
}

location ~ /\.(?!well-known(?:/|$)) {
    return 404;
}

Uruchom skan ponownie; znalezisko powinno zniknąć (adres URL zwraca teraz 403/404). Jeśli w tej historii kiedykolwiek znajdował się jakiś sekret, wymień go na nowy.

Co naprawić w pierwszej kolejności (wraz z poleceniami)

Przerabiaj raport od góry do dołu. Oto poprawki dla znalezisk, które będziesz widywać najczęściej.

Archiwa kopii zapasowych w katalogu głównym serwisu

Plik store.sql czy backup.zip obok index.php to pełna kopia Twojego sklepu, oddalona o jedno zgadnięcie nazwy. Najpierw je wylistuj, a potem przenieś każde trafienie poza docroot (mv -n nigdy nie nadpisuje):

# review the list first
find . -maxdepth 2 -type f \
  \( -name '*.sql' -o -name '*.sql.gz' -o -name '*.zip' -o -name '*.tar.gz' -o -name '*.bak' \) -ls

# then move every match out of the webroot
mkdir -p "$HOME/private-backups"
find . -maxdepth 2 -type f \
  \( -name '*.sql' -o -name '*.sql.gz' -o -name '*.zip' -o -name '*.tar.gz' -o -name '*.bak' \) \
  -exec mv -n -- {} "$HOME/private-backups/" \;

Pozostawiony katalog /install

PrestaShop każe go usunąć po zakończeniu instalacji. Zamiast kasować od razu, poddaj go kwarantannie (uruchom z katalogu głównego sklepu):

# run from your shop root
set -eu
test -f config/config.inc.php

backup="$HOME/prestashop-install-dirs-$(date +%F-%H%M%S)"
mkdir -p "$backup"
[ -d install ] && mv install "$backup/"
[ -d install-dev ] && mv install-dev "$backup/"

Włączony tryb debugowania

Tryb deweloperski ujawnia odwiedzającym stack trace'y i ścieżki. Zmień istniejącą linię w config/defines.inc.php (lub config/defines_custom.inc.php) — nie dopisuj drugiej poniżej:

<?php
// change the EXISTING _PS_MODE_DEV_ line to false (never true on a live shop)
define('_PS_MODE_DEV_', false);

Katalogi zapisywalne dla wszystkich (0777)

Skaner oznacza katalogi z uprawnieniami 0777. Przywróć uprawnienia zgodne z zasadą najmniejszych przywilejów — nigdy chmod 777 — i utrzymuj poufne pliki konfiguracyjne nieczytelnymi dla innych (czytelny dla wszystkich parameters.php to samo w sobie znalezisko). Uruchom z katalogu głównego sklepu:

# run from your shop root; set these to your real PHP-FPM/web user + group
WEB_USER=www-data
WEB_GROUP=www-data

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

# lock down the secret config files: owned by the web user, readable by owner+group only
# (never world-readable — but still readable by the PHP process). Adjust owner/group above.
for f in app/config/parameters.php config/settings.inc.php; do
  [ -f "$f" ] || continue
  chown "$WEB_USER:$WEB_GROUP" "$f"
  chmod 640 "$f"
done

# only the writable dirs need to be owned by the web user
for dir in var/cache var/logs img upload download; do
  [ -d "$dir" ] || continue
  chown -R "$WEB_USER:$WEB_GROUP" "$dir"
  find "$dir" -type d -exec chmod 775 {} \;
  find "$dir" -type f -exec chmod 664 {} \;
done

Słaby lub brakujący .htaccess

Wygeneruj ponownie reguły ochronne PrestaShop z panelu administracyjnego (Parametry sklepu → Ruch i SEO → Wygeneruj ponownie plik .htaccess), a następnie potwierdź, że wrażliwe pliki są zablokowane, a listowanie katalogów wyłączone. Minimalne zabezpieczenie:

<FilesMatch "(?i)(parameters\.php|settings\.inc\.php|\.env|composer\.(json|lock))$">
  Require all denied
</FilesMatch>

Options -Indexes

Ograniczenia samego wykrywania

Szczerość co do ograniczeń to część dobrego korzystania z każdego narzędzia bezpieczeństwa: ono wykrywa problemy, ale nie naprawia ich za Ciebie; kontrole heurystyczne mogą oznaczyć coś niegroźnego (zweryfikuj przed usunięciem); pokrycie biuletynów jest starannie dobierane, ale nie wyczerpujące; i nie jest to test penetracyjny. Po pełne kompendium naprawcze — hartowanie serwera, zabezpieczenie panelu administracyjnego, bazę danych i monitoring — sięgnij do listy kontrolnej hartowania bezpieczeństwa.

Kiedy przestać skanować i poprosić o pomoc

Niektóre znaleziska oznaczają, że czas na człowieka, a nie narzędzie. Pliki wyglądające na malware, cokolwiek przypominającego skimmer płatności, konta administratorów, których nie rozpoznajesz, ujawnione dane dostępowe albo powtarzające się reinfekcje — to już incydent. Jeśli wolisz przekazać to nam, zamów audyt bezpieczeństwa.

Kiedy automatyczne naprawy mają sens

Darmowy skaner jest celowo narzędziem jednorazowego użytku: uruchamiasz go, czytasz raport i naprawiasz wszystko ręcznie. Idealny do okazjonalnego przeglądu. Jeśli wolisz nie robić tego ręcznie — albo chcesz, by sklep pozostał naprawiony — Security Revolution stosuje naprawy jednym kliknięciem, hartuje sklep, monitoruje integralność plików rdzenia, ostrzega, gdy coś się zmieni, i zarządza całą flotą sklepów z jednego panelu. Te same znaleziska; on po prostu na nie reaguje i dalej czuwa.

FAQ

Czy skan wysyła gdzieś moje dane? Przy samodzielnym skanie z panelu lub z CLI — nie: raport zostaje na Twoim serwerze, a jedyne wychodzące żądania to autotesty Twoich własnych publicznych adresów URL, zabezpieczone przed dostępem do adresów wewnętrznych (SSRF). Jeśli świadomie włączysz opcjonalny łącznik floty, wyniki skanów są wysyłane — podpisanym kanałem — do skonfigurowanego przez Ciebie huba.

Czy naprawia problemy automatycznie? Nie — ten moduł służy wyłącznie do wykrywania. Automatyczne naprawy i monitoring znajdziesz w Security Revolution.

Czy jest bezpieczny na działającym sklepie? Tak. Odczytuje pliki, konfigurację i bazę danych, a zapisuje wyłącznie własny wpis w historii skanów — nigdy nie modyfikuje treści sklepu, ustawień, produktów, zamówień ani klientów.

Jak często skanować? Po każdej aktualizacji PrestaShop lub modułu i co najmniej raz w miesiącu. Strona Historia śledzi Twój wynik w czasie.

Czy zastąpi programistę? Nie. To szybki, użyteczny pierwszy przegląd, który wyłapuje częste, dobrze znane ryzyka. Dogłębne audyty i prawdziwe incydenty nadal wymagają człowieka.

Powiązane materiały

• Hartowanie bezpieczeństwa PrestaShop: kompletna lista kontrolna — naprawcze uzupełnienie tej strony.
• Security Scan — opisany tu darmowy moduł.
• Security Revolution — automatyczne naprawy, hartowanie i monitoring integralności plików.