Dwa tygodnie temu na GitHub’ie pojawiło się bardzo ciekawe narzędzie Argus przeznaczone do weryfikacji zabezpieczeń witryn internetowych zbudowanych z wykorzystaniem najpopularniejszego systemu CMS – WordPress (obsługuje około 43% wszystkich witryn dostępnych w Internecie). Autorem Argusa jest hiszpański programista full stack Rodney Dhavid Jiménez Chacín. Narzędzie jest zdecydowanie warte uwagi z powodu prostoty używania, gotowości do użycia AI, ale również możliwości przygotowania przejrzystego i zwyczajnie ładnego raportu z testów – to może nie jest najważniejsza funkcjonalność, ale w porównaniu do innych (w tym komercyjnych) rozwiązań do testów bezpieczeństwa szablon raportu HTML z Argusa jest naprawdę dobrze sformatowany.
Ograniczenie zastosowania do samego WordPress może okazać się dużą zaletą Argusa. Lepiej dostosować narzędzie pod konkretny system (który przecież i tak jest rozbudowaną platformą) niż tworzyć kolejne proste skrypty obsługujące wszystkie systemy CMS/frameworki (niezależnie od języka programowania), ale za to znajdujące tylko podstawowe błędy – a tych może być bardzo mało, bo znane rozwiązania do budowania aplikacji posiadają odpowiednie zabezpieczenia „by design” (co oczywiście nie wyklucza sensowności testów bezpieczeństwa). Tym bardziej że w przypadku WordPress niestety łatwo o zastosowanie kiepskiej konfiguracji (także serwera HTTP – pewne charakterystyczne błędy dla aplikacji PHP), a powszechna znajomość kodu i obsługi tego systemu nie jest pozytywną wiadomością z punktu widzenia bezpieczeństwa.
Argus napisany został w języku Python, więc z założenia można stwierdzić, że przygotowanie środowiska do uruchamiania testów nie będzie złożonym procesem. W repozytorium dostępne są też gotowe obrazy Dockerfile i pliki docker-compose.yml. Odpowiednie instrukcje są szczegółowo przedstawione w README.
W celu zaprezentowania Argusa uruchomiłem dwa lokalne środowiska. Pierwsze z nich – test-wp.avlab.pl – zawiera zainstalowany system WordPress, a kolejne – test-bedrock.avlab.pl – specjalną, customową wersję tego systemu nazwaną Bedrock (mocno polecam zapoznać się z tym tematem pod adresem https://roots.io/bedrock/). Oba środowiska działają na ustawieniach domyślnych (wykonana została jedynie instalacja WordPress), co udowodni, że zmodyfikowana struktura katalogów (m.in. plik .env z konfiguracją strony – alternatywa dla wp-config.php – znajdujący się katalog wyżej od katalogu root witryny) zastosowana w Bedrock ma duże znaczenie w kontekście bezpieczeństwa.
Oba środowiska mają zastosowaną konfigurację serwerów HTTP, którą można określić jako „działającą” – spełnia swoje założenia (obsługa HTTPS, interpreter PHP), ale nie wykonano żadnego hardeningu konfiguracji. Jest to absolutnie minimalna konfiguracja umożliwiająca prawidłowe działanie systemu WordPress, jak i praktycznie dowolnej innej aplikacji napisanej w języku PHP.
Należy też zaznaczyć, że Argus wykonuje testy w dwóch trybach – normalnym (domyślnie) i „agresywnym”. Na wyróżnienie zasługuje fakt, że drugi z tych trybów wymaga udowodnienia, że osoba wykonująca test posiada jakiekolwiek uprawnienia do zarządzania danym serwisem WordPress i w związku tym musi umieścić specjalny plik w podanej lokalizacji bądź dodać odpowiednie rekordy DNS. Takie zabezpieczenie w skrypcie interpretowanego języka Python nie jest może szczególnie wygórowane, natomiast z dużą pewnością skutecznie ogranicza wykorzystanie Argusa przez tzw. script-kiddies – osoby z małą wiedzą techniczną, które chcą użyć swoich „umiejętności hakerskich”. Implementacja tego rozwiązania nie jest zresztą standardem na rynku podobnych narzędzi.
Podstawowe opcje Argus
Na początku warto przedstawić najbardziej użyteczne parametry dostępne w narzędziu Argus.
Normalne skanowanie witryny:
python -m argus --target https://test-wp.avlab.pl
Normalne skanowanie witryny + raport HTML:
python -m argus --target https://test-wp.avlab.pl –html
Weryfikacja uprawnień do testowanej witryny (metoda z plikiem tekstowym) + agresywne skanowanie + raport HTML:
python -m argus --gen-consent test-wp.avlab.pl
#dodanie pliku na serwerze
python -m argus --verify-consent http --domain test-wp.avlab.pl --token verify-9a8feb89a6ae286a
python -m argus --target https:// test-wp.avlab.pl --aggressive –html
Test 1: WordPress z ustawieniami domyślnymi – normal
Argus znalazł łącznie 24 podatności, z czego 2 o statusie High i 8 podatności Medium. Zdecydowanie jednak powinniśmy sprawdzić też podatności Low i Info, bo zawierają przydatne informacje dotyczące m.in. nagłówków, które warto ustawić.
Raport do pobrania w tym miejscu.
Test 2: WordPress z ustawieniami domyślnymi – aggresive
Pomimo trybu aggresive zostały znalezione dokładnie te same podatności, co w przypadku normalnego skanowania.
Raport do pobrania w tym miejscu.
Hardening WordPress
W raportach wygenerowanych przez Argus przy każdej wykrytej podatności podana jest skondensowana instrukcja rozwiązania danego problemu. Część z nich jest typowa dla WordPress, ale ogólne zasady bezpieczeństwa pozostają takie same niezależnie od zastosowanego oprogramowania, dlatego warto zapoznać się z niżej opisanymi podatnościami.
WordPress core version disclosed
Przeglądając kod witryn opartych na WordPress, można spotkać ten meta tag:
Informacje o zainstalowanej wersji znajdują się też w RSS feed (?feed=rss2).
https://wordpress.org/?v=6.9
To poważny błąd, bo dysponując numerem wersji, bez większych trudności można odszukać podatności przeznaczone dla konkretnych wydań WordPress. Podobna zasada dotyczy serwerów HTTP, które w nagłówkach Server i X-Powered-By wysyłają m.in.:
HTTP/2 200
server: nginx/1.20.1
date: Sun, 07 Dec 2025 17:48:25 GMT
content-type: text/html; charset=UTF-8
x-powered-by: PHP/8.5.0
link: ; rel=https://api.w.org/
W przypadku WordPress dobrym rozwiązaniem będzie użycie wtyczki Meta Generator and Version Info Remover – wystarczy ją zainstalować i aktywować.
7 security header/cookie issue(s) detected [Missing security header: HSTS (HTTP Strict Transport Security), Missing security header: Content Security Policy (CSP), Missing security header: X-Frame-Options, Missing security header: X-Content-Type-Options, Missing security header: X-XSS-Protection (Legacy), Missing security header: Referrer-Policy, Missing security header: Permissions-Policy]
Wszystkie problem z tej kategorii rozwiążemy wtyczką Headers Security Advanced & HSTS WP. Po aktywacji wymienionej wtyczki do pliku .htaccess została dodana następująca zawartość:
# BEGIN Headers Security Advanced & HSTS WP 5.2.4
Header set Access-Control-Allow-Methods "GET,POST"
Header set Access-Control-Allow-Headers "Content-Type, Authorization"
Header set Content-Security-Policy "upgrade-insecure-requests;"
Header set Cross-Origin-Embedder-Policy "unsafe-none; report-to='default'"
Header set Cross-Origin-Embedder-Policy-Report-Only "unsafe-none; report-to='default'"
Header set Cross-Origin-Opener-Policy "unsafe-none"
Header set Cross-Origin-Opener-Policy-Report-Only "unsafe-none; report-to='default'"
Header set Cross-Origin-Resource-Policy "cross-origin"
Header set Permissions-Policy "accelerometer=(), autoplay=(), camera=(), cross-origin-isolated=(), display-capture=(self), encrypted-media=(), fullscreen=*, geolocation=(self), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), payment=*, picture-in-picture=*, publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=*, usb=(), xr-spatial-tracking=(), gamepad=(), serial=()"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set Strict-Transport-Security "max-age=63072000"
Header set X-Content-Security-Policy "default-src 'self'; img-src *; media-src * data:;"
Header set X-Content-Type-Options "nosniff"
Header set X-Frame-Options "SAMEORIGIN"
Header set X-Permitted-Cross-Domain-Policies "none"
# END Headers Security Advanced & HSTS WP
Pliki .htaccess są obsługiwane przez serwer Apache. Jeśli korzystamy z innego serwera HTTP (takiego jak nginx), to widoczne nagłówki należy dodać w konfiguracji konkretnego vhosta.
Konfiguracja HSTS zaproponowana przez tę wtyczkę nie jest najlepsza. Argus w rekomendacjach wypisuje ustawienia zgodne z poniższym zrzutem ekranu.
Argus weryfikuje obecność nagłówka X-XSS-Protection. Jest to przestarzałe „zabezpieczenie”, ale jego dodanie nie będzie mieć wpływ na działanie serwisu.
Header set X-XSS-Protection "1; mode=block"
2 sensitive file(s) exposed [WordPress readme.html accessible, Sensitive file exposed: license.txt]
Wymienione pliki w zupełności można usunąć – nie są powiązane z kodem systemu WordPress, a ich obecności na serwerze nie można uzasadnić.
XML-RPC partially restricted (Good)
To akurat błąd w logice Argus, ponieważ wykonane zostało żądanie GET, które nie jest dozwolone przez skrypt xmlrpc.php – musi to być typ POST. Różnicę w odpowiedzi prezentuje poniższy listing.
[avlab@testy ~]$ curl -I https://test-wp.avlab.pl/xmlrpc.php
HTTP/2 405
server: nginx/1.20.1
date: Mon, 08 Dec 2025 07:47:06 GMT
content-type: text/plain;charset=UTF-8
x-powered-by: PHP/8.5.0
allow: POST
(….)
[avlab@testy ~]$ curl -I -XPOST https://test-wp.avlab.pl/xmlrpc.php
HTTP/2 200
server: nginx/1.20.1
date: Mon, 08 Dec 2025 07:47:16 GMT
content-type: text/xml; charset=UTF-8
x-powered-by: PHP/8.5.0
(…)
Dostęp do tego pliku może być całkowicie zablokowany. Przykład dla serwera Apache:
deny from all
Admin login page publicly accessible
Istotna uwaga, ponieważ dostępność /wp-login.php naraża (przy założeniu, że nie zastosowano przykładowo ochrony CAPTCHA) hostowaną witrynę na ataki brute-force. Dodatkowo inny adres logowania do Kokpitu wygląda bardziej profesjonalnie. Do zmiany służy wtyczka WPS Hide Login.
1 user(s) enumerated [User enumerated: avlab]
Ukrycie nazw użytkowników pozostaje dobrą praktyką, a w przypadku systemu WordPress najszybszą metodą będzie użycie wtyczki Stop User Enumeration.
Zbędne motywy i wtyczki
Oprócz tego w raporcie znajdują się informacje o wykryciu popularnych motywów i wtyczek. Niektóre są zainstalowane domyślnie. Powinny zostać usunięte, aby zminimalizować szanse na ewentualne podatności. Zresztą dla samej wygody zarządzania witryną WordPress ważne jest utrzymanie pewnej „higieny” i regularne przeglądy, czy na pewno wszystkie zainstalowane komponenty są w dalszym ciągu wymagane.
Test 3: WordPress po hardeningu (wdrożone zalecenia z raportu) – aggressive
Jak można się było spodziewać, otrzymane wyniku testu bezpieczeństwa są teraz wzorcowe – nie wykryto żadnych podatności.
Raport do pobrania w tym miejscu.
Test 4: Bedrock z ustawieniami domyślnymi – aggresive
Ten test pokazuje dużą „przewagę” zmodyfikowanego systemu WordPress nad standardową wersją. Najprostsze błędy, które można znaleźć w każdej nowej instalacji WordPress, nie zostały znalezione.
Raport do pobrania w tym miejscu.
Podsumowanie
WordPress to znany każdemu system, który dzięki swojej prostocie, a następnie dużej ilości motywów i wtyczek osiągnął gigantyczną popularność. Stał się też celem ataków. Niestety domyślna konfiguracja jest dość kiepska z punktu widzenia bezpieczeństwa. W związku z tym zalecane jest wdrożenie opisanych wyżej zmian oraz częste testy weryfikujące podatności. Nie zaszkodzi też migracja na wersję Bedrock, która dodatkowo jest znacznie lepiej dostosowana pod kątem rozwoju aplikacji przez programistów.
Z kolei Argus ma duży potencjał i pozostaje mieć nadzieję, że w przyszłości stanie się jednym z kluczowych narzędzi wykorzystywanych w testach systemu WordPress. Pomijając drobne błędy – jak ten z weryfikacją xmlrpc.php – na tę chwilę jest to całkiem dobre rozwiązanie. Widać, że do repozytorium nie została wysłana wersja „initial”, gdzie autor oczekuje, że inni użytkownicy znajdą (a najlepiej rozwiążą w ramach pull requestów) problemy w kodzie.
Czy ten artykuł był pomocny?
Oceniono: 0 razy



