W module Faceted Search (ps_facetedsearch) zidentyfikowano podatność bezpieczeństwa. W określonych okolicznościach odpowiednio przygotowane żądania mogą zostać nieprawidłowo obsłużone przez moduł, co może umożliwić uruchomienie nieautoryzowanego kodu na serwerze. Co istotne, wykorzystanie tej luki nie wymaga logowania ani posiadania konta użytkownika, dlatego każdy sklep korzystający z podatnej wersji modułu jest narażony na ryzyko.
Problem został usunięty w wersji 4.0.4 modułu. Jeśli korzystasz z ps_facetedsearch, zaleca się niezwłoczną aktualizację do tej wersji. Jest to jedyna metoda całkowitego wyeliminowania podatności.
W przypadku korzystania z ps_facetedsearch aktualizacja do wydania 4.0.4 powinna być priorytetem. Dodatkowe środki bezpieczeństwa opisane w dalszej części mogą zwiększyć ochronę sklepu, jednak to właśnie aktualizacja usuwa źródło problemu.
Podatność dotyczy wszystkich wersji ps_facetedsearch od 3.0.0 do 4.0.3 włącznie, działających na sklepach opartych o PrestaShop 1.7.1.0 lub nowszy.
Błąd został naprawiony w wersji 4.0.4.
Szczegółowe informacje można znaleźć w oficjalnym komunikacie bezpieczeństwa.
Ze względu na dużą popularność modułu, który odpowiada za filtrowanie produktów w wielu sklepach PrestaShop, oraz fakt, że atak nie wymaga uwierzytelnienia, aktualizacja powinna zostać potraktowana jako pilna przez wszystkich użytkowników tego rozwiązania.
Najlepszym rozwiązaniem jest instalacja najnowszej dostępnej wersji modułu:
Po zakończeniu procesu upewnij się, że w panelu administracyjnym widnieje wersja 4.0.4 lub nowsza.
Pełne zabezpieczenie zapewnia wyłącznie aktualizacja do wersji 4.0.4. Jeżeli z przyczyn technicznych nie możesz jej wdrożyć natychmiast (np. ze względu na indywidualne modyfikacje modułu lub procedury wdrożeniowe), bardziej zaawansowani użytkownicy mogą samodzielnie zastosować oficjalną poprawkę udostępnioną w repozytorium źródłowym.
Ręczne zastosowanie poprawki należy traktować wyłącznie jako rozwiązanie tymczasowe. Choć eliminuje ono tę konkretną lukę, nie zawiera innych usprawnień i poprawek wprowadzonych w kolejnych wydaniach modułu. Dlatego aktualizacja do wersji 4.0.4 nadal powinna zostać wykonana przy najbliższej okazji.
Jeśli nie masz doświadczenia w modyfikowaniu plików działającego sklepu, najpierw przetestuj zmiany na środowisku testowym lub skorzystaj z pomocy specjalisty PrestaShop.
Nawet po aktualizacji warto zweryfikować, czy podatność nie została wykorzystana wcześniej.
Połącz się z serwerem przez FTP lub SSH i sprawdź:
modules/ps_facetedsearch/ oraz jego podfolderach nie znajdują się nieznane pliki PHP. Moduł posiada określony zestaw plików, dlatego każdy dodatkowy lub podejrzany plik .php powinien wzbudzić czujność.modules/ps_facetedsearch.Dodatkowo możesz przejrzeć stronę „Parametry Zaawansowane → Informacje” w panelu administracyjnym, gdzie prezentowana jest lista zmodyfikowanych plików systemowych. Sam ten test nie daje jednak pewności, że sklep nie został naruszony.
W przypadku wykrycia podejrzanych plików, nietypowej aktywności w logach lub innych oznak włamania, nie zakładaj, że sama aktualizacja rozwiąże problem. Sklep, który został już skompromitowany, wymaga dokładnej analizy i oczyszczenia.
Zaleca się:
Poniższe działania zwiększają poziom ochrony i ograniczają skutki potencjalnych ataków. Nie zastępują one jednak aktualizacji modułu do wersji 4.0.4.
Zapora aplikacyjna analizuje przychodzące żądania HTTP i może blokować ruch odpowiadający znanym wzorcom ataków jeszcze przed dotarciem do PrestaShop.
WAF stanowi wartościową dodatkową warstwę ochrony, jednak nie należy traktować go jako rozwiązania problemu. Mechanizmy oparte na sygnaturach mogą zostać ominięte przez odpowiednie zmodyfikowanie żądania. Dlatego aktualizacja pozostaje podstawowym środkiem naprawczym.
Rozwiązania takie jak Cloudflare, CDN-y czy reverse proxy mogą pomóc w filtrowaniu ruchu oraz stosowaniu reguł bezpieczeństwa już na poziomie infrastruktury brzegowej.
Mimo że odpowiednio skonfigurowane reguły mogą zatrzymać część prób ataków, nie gwarantują pełnej ochrony. Filtrowanie opiera się na rozpoznawaniu określonych wzorców i może zostać ominięte. Z tego względu nie powinno być traktowane jako alternatywa dla aktualizacji.
Wyłączenie funkcji PHP umożliwiających wykonywanie poleceń systemowych znacząco ogranicza możliwości potencjalnego atakującego.
W pliku php.ini można ustawić:
disable_functions = exec,passthru,shell_exec,system,proc_open,popen,proc_close,proc_nice,pcntl_exec,popen,proc_get_status
Szczególnie warto rozważyć wyłączenie funkcji:
Standardowe działanie PrestaShop nie wymaga korzystania z tych funkcji, jednak niektóre moduły lub konfiguracje hostingowe mogą ich używać. Przed wdrożeniem zmian na środowisku produkcyjnym należy przeprowadzić testy.
Jeżeli korzystasz z ps_facetedsearch w wersji 3.0.0 lub nowszej, ale starszej niż 4.0.4, zaktualizuj moduł jak najszybciej. Dodatkowo sprawdź katalog modules/ps_facetedsearch/ oraz logi serwera pod kątem oznak wcześniejszych prób ataków. Wdrożenie WAF-a, filtrowania ruchu na poziomie CDN oraz ograniczenie wybranych funkcji PHP mogą zwiększyć poziom bezpieczeństwa, jednak nie zastępują aktualizacji.