WordPress domyślnie pokazuje swój numer wersji w kilku miejscach. Sama w sobie nie jest to krytyczna podatność. Ale daje atakującym przewagę. Jeśli ktoś wie, że uruchamiasz WordPress 6.2.1, może sprawdzić każdy znany exploit dla tej konkretnej wersji i wypróbować go na Twojej witrynie. Usunięcie informacji o wersji to prosty pierwszy krok, który czyni automatyczne narzędzia skanujące mniej skutecznymi.
Gdzie WordPress ujawnia numer wersji
WordPress jest zaskakująco hojny w ujawnianiu, jaką wersję uruchamia. Oto najczęstsze miejsca, w których atakujący (i każdy, kto przegląda Twój kod źródłowy) mogą go znaleźć:
- Meta tag generator: WordPress dodaje tag
<meta name="generator" content="WordPress 6.x.x">do sekcji<head>każdej strony. Jest to najbardziej oczywiste miejsce i pojawia się przy każdym wywołaniu strony. - Kanały RSS i Atom: Kanał RSS Twojej witryny (zazwyczaj pod
/feed/) zawiera element<generator>z pełnym ciągiem wersji WordPress. Wielu właścicieli witryn całkowicie zapomina o kanałach, pozostawiając ten wektor otwarty. - Query stringi skryptów i arkuszy stylów: WordPress dodaje
?ver=6.x.xdo URL plików CSS i JavaScript, gdy je dodaje. Nawet jeśli usuniesz meta tag, ten parametr nadal rozgłasza Twoją wersję przy każdym żądaniu zasobu. - Plik readme.html: WordPress jest dostarczany z plikiem
readme.htmlw głównym katalogu. Plik ten zawiera numer wersji w postaci jawnej i jest dostępny dla każdego, kto zna URL. - Plik license.txt: Podobnie jak
readme.html, pliklicense.txtznajduje się w korzeniu WordPress i może potwierdzić, że witryna używa WordPress. - Kod źródłowy strony logowania: Strona logowania WordPress pod
/wp-login.phpładuje arkusze stylów i skrypty z query stringami wersji, co czyni ją kolejnym źródłem informacji o wersji. - Odpowiedzi REST API: Korzeń REST API WordPress pod
/wp-json/również może ujawnić szczegóły wersji w nagłówkach odpowiedzi lub treści.
Dlaczego ukrywanie wersji ma znaczenie
Każde duże wydanie WordPress ma publiczny changelog. Gdy wydawany jest patch bezpieczeństwa, podatność, którą naprawia, staje się informacją publiczną. Automatyczne boty stale skanują sieć w poszukiwaniu witryn nadal uruchamiających starą, podatną wersję. Jeśli Twoja witryna reklamuje "WordPress 6.2.1" i krytyczna luka SQL injection została załatana w 6.2.2, Twoja witryna staje się celem w ciągu kilku godzin od wydania patcha.
Ukrywanie numeru wersji nie naprawia samej podatności. Po prostu usuwa jeden punkt danych, którego atakujący używają do priorytetyzacji celów. Pomyśl o tym jak o usunięciu numeru domu z listy domów z niezamkniętymi drzwiami. Drzwi mogą nadal być niezamknięte, ale przynajmniej nie jesteś na liście priorytetowej.
Usuń wersję z HTML i kanałów
Dodaj poniższy kod do pliku functions.php swojego motywu lub, lepiej, do wtyczki specyficznej dla witryny, aby przetrwał zmiany motywu:
// Remove the generator meta tag from HTML head
remove_action('wp_head', 'wp_generator');
// Remove version from RSS feeds
add_filter('the_generator', '__return_empty_string');
// Remove version query string from scripts and styles
function remove_wp_version_from_assets($src) {
if (strpos($src, 'ver=' . get_bloginfo('version'))) {
$src = remove_query_arg('ver', $src);
}
return $src;
}
add_filter('style_loader_src', 'remove_wp_version_from_assets', 9999);
add_filter('script_loader_src', 'remove_wp_version_from_assets', 9999);Wywołanie remove_action usuwa meta tag. Filtr the_generator obsługuje kanały RSS i Atom. Dwa filtry loader usuwają parametr ?ver= ze wszystkich dodawanych zasobów. Użycie priorytetu 9999 zapewnia, że jest to wykonywane po dodaniu skryptów przez wtyczki i motywy.
Usuń readme.html i license.txt
Te statyczne pliki znajdują się w głównym katalogu WordPress i zawierają informacje o wersji. Usuń je:
rm /sciezka/do/wordpress/readme.html
rm /sciezka/do/wordpress/license.txtJest jedno zastrzeżenie: WordPress odtwarza te pliki podczas aktualizacji core. Masz dwie opcje, aby to obsłużyć. Możesz usuwać je ręcznie po każdej aktualizacji. Lub możesz dodać mały skrypt do procesu wdrożenia, który usunie je automatycznie. Jeśli używasz WP-CLI, dobrze sprawdzi się tu hook post-update.
Podejścia oparte na wtyczkach
Jeśli wolisz nie edytować plików kodu, kilka wtyczek obsługuje usuwanie wersji za Ciebie. Wtyczki bezpieczeństwa takie jak Wordfence, iThemes Security i All In One WP Security zawierają opcje ukrywania wersji WordPress. Lekkie opcje takie jak Meta Generator and Version Info Remover skupiają się specjalnie na tym zadaniu bez dodawania dodatkowego narzutu.
Wybierając wtyczkę, upewnij się, że pokrywa wszystkie wymienione wyżej lokalizacje, a nie tylko meta tag. Niektóre wtyczki usuwają tylko tag generator i pozostawiają query stringi skryptów nietknięte.
Bezpieczeństwo przez obscurity nie wystarczy
Ukrywanie wersji WordPress to dobra praktyka, ale sama w sobie nie jest strategią bezpieczeństwa. Zdeterminowany atakujący nadal może odcisnąć palec Twojej wersji WordPress innymi metodami, takimi jak porównanie zawartości plików JavaScript core lub sprawdzanie obecności określonych funkcji wprowadzonych w określonych wydaniach.
Dla prawdziwego bezpieczeństwa musisz połączyć ukrywanie wersji z podstawami:
- Utrzymuj WordPress, motywy i wtyczki zaktualizowane: To najważniejsza rzecz, jaką możesz zrobić. Większość włamań WordPress wykorzystuje znane podatności w przestarzałym oprogramowaniu.
- Używaj silnych haseł i uwierzytelniania dwuskładnikowego: Ataki brute-force na
wp-login.phppozostają jednym z najczęstszych wektorów ataku. - Zainstaluj web application firewall (WAF): Usługi takie jak Cloudflare, Sucuri lub WAF oparty na wtyczce mogą blokować złośliwe żądania, zanim dotrą do WordPress.
- Ogranicz próby logowania: Wtyczki takie jak Limit Login Attempts Reloaded zapobiegają wykonywaniu przez atakujących automatycznych ataków zgadywania haseł.
- Wyłącz XML-RPC, jeśli go nie potrzebujesz: XML-RPC to kolejny powszechny wektor ataku dla brute-force i amplifikacji DDoS.
Weryfikacja zmian z InspectWP
Po wdrożeniu tych zmian uruchom nowe skanowanie InspectWP swojej witryny. Sprawdź sekcję WordPress raportu. Numer wersji nie powinien już pojawiać się w kodzie źródłowym HTML, a meta tag generator powinien zniknąć. Jeśli InspectWP nadal wykrywa wersję, sprawdź, czy fragment kodu został poprawnie załadowany i czy wtyczki cachujące nie serwują przestarzałej wersji Twoich stron.