WordPress toont standaard zijn versienummer op verschillende plaatsen. Op zichzelf is dit geen kritieke kwetsbaarheid. Maar het geeft aanvallers een voorsprong. Als iemand weet dat u WordPress 6.2.1 draait, kan hij elke bekende exploit voor die specifieke release opzoeken en tegen uw site proberen. Het verwijderen van versie-informatie is een eenvoudige eerste stap die geautomatiseerde scantools minder effectief maakt.
Waar WordPress het versienummer blootlegt
WordPress is verrassend gul met het onthullen welke versie het draait. Hier zijn de meest voorkomende plekken waar aanvallers (en iedereen die uw broncode bekijkt) het kunnen vinden:
- Generator-metatag: WordPress voegt een
<meta name="generator" content="WordPress 6.x.x">-tag toe aan de<head>-sectie van elke pagina. Dit is de meest voor de hand liggende plek en verschijnt bij elke pagina-aanroep. - RSS- en Atom-feeds: De RSS-feed van uw site (meestal op
/feed/) bevat een<generator>-element met de volledige WordPress-versietekenreeks. Veel site-eigenaren vergeten feeds volledig, waardoor deze vector openblijft. - Querystrings van scripts en stylesheets: WordPress voegt
?ver=6.x.xtoe aan CSS- en JavaScript-bestand-URL's wanneer het deze toevoegt. Zelfs als u de metatag verwijdert, verspreidt deze parameter nog steeds uw versie bij elk asset-verzoek. - Het bestand readme.html: WordPress wordt geleverd met een
readme.html-bestand in de hoofddirectory. Dit bestand bevat het versienummer in platte tekst en is toegankelijk voor iedereen die de URL kent. - Het bestand license.txt: Net als
readme.htmlstaat het bestandlicense.txtin de WordPress-root en kan bevestigen dat de site WordPress draait. - De broncode van de inlogpagina: De WordPress-inlogpagina op
/wp-login.phplaadt stylesheets en scripts met versie-querystrings, waardoor het een andere bron van versie-informatie wordt. - REST API-responsen: De WordPress REST API-root op
/wp-json/kan ook versiedetails onthullen in de respons-koptekst of body.
Waarom het verbergen van de versie belangrijk is
Elke grote WordPress-release heeft een openbare changelog. Wanneer een beveiligingspatch wordt uitgebracht, wordt de kwetsbaarheid die deze verhelpt openbare informatie. Geautomatiseerde bots scannen continu het web op zoek naar sites die nog de oude, kwetsbare versie draaien. Als uw site adverteert met "WordPress 6.2.1" en een kritieke SQL-injectie is gepatcht in 6.2.2, wordt uw site binnen enkele uren na de patchrelease een doelwit.
Het verbergen van het versienummer verhelpt de kwetsbaarheid zelf niet. Het verwijdert eenvoudigweg één gegevenspunt dat aanvallers gebruiken om doelen te prioriteren. Zie het als het verwijderen van uw huisnummer van een lijst met huizen met onafgesloten deuren. De deur is mogelijk nog steeds onafgesloten, maar u staat in ieder geval niet op de shortlist.
Verwijder de versie uit HTML en feeds
Voeg de volgende code toe aan het functions.php-bestand van uw thema of, beter nog, aan een site-specifieke plugin zodat deze themawijzigingen overleeft:
// 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);De aanroep remove_action verwijdert de metatag. Het filter the_generator handelt RSS- en Atom-feeds af. De twee loader-filters verwijderen de ?ver=-parameter uit alle toegevoegde assets. Het gebruik van prioriteit 9999 zorgt ervoor dat dit wordt uitgevoerd nadat plugins en thema's hun eigen scripts hebben toegevoegd.
Verwijder readme.html en license.txt
Deze statische bestanden staan in uw WordPress-hoofddirectory en bevatten versie-informatie. Verwijder ze:
rm /pad/naar/wordpress/readme.html
rm /pad/naar/wordpress/license.txtEr is een kanttekening: WordPress maakt deze bestanden opnieuw aan tijdens core-updates. U heeft twee opties om dit af te handelen. U kunt ze handmatig verwijderen na elke update. Of u kunt een klein script aan uw deploymentproces toevoegen dat ze automatisch verwijdert. Als u WP-CLI gebruikt, werkt een post-update-hook hier goed voor.
Plugin-gebaseerde aanpakken
Als u liever geen codebestanden bewerkt, handelen verschillende plugins versieverwijdering voor u af. Beveiligingsplugins zoals Wordfence, iThemes Security en All In One WP Security bevatten allemaal opties om de WordPress-versie te verbergen. Lichte opties zoals Meta Generator and Version Info Remover richten zich specifiek op deze taak zonder extra overhead toe te voegen.
Zorg er bij het kiezen van een plugin voor dat deze alle hierboven genoemde locaties dekt, niet alleen de metatag. Sommige plugins verwijderen alleen de generator-tag en laten script-querystrings ongemoeid.
Beveiliging door obscuriteit is niet voldoende
Het verbergen van uw WordPress-versie is een goede praktijk, maar het is op zichzelf geen beveiligingsstrategie. Een vastberaden aanvaller kan uw WordPress-versie nog steeds vingerafdrukken via andere methoden, zoals het vergelijken van de inhoud van core JavaScript-bestanden of controleren op de aanwezigheid van specifieke functies geïntroduceerd in bepaalde releases.
Voor echte beveiliging moet u versie verbergen combineren met de basis:
- Houd WordPress, thema's en plugins bijgewerkt: Dit is het allerbelangrijkste wat u kunt doen. De meeste WordPress-hacks misbruiken bekende kwetsbaarheden in verouderde software.
- Gebruik sterke wachtwoorden en tweefactorauthenticatie: Brute-force-aanvallen tegen
wp-login.phpblijven een van de meest voorkomende aanvalsvectoren. - Installeer een web application firewall (WAF): Diensten zoals Cloudflare, Sucuri of een plugin-gebaseerde WAF kunnen kwaadaardige verzoeken blokkeren voordat ze WordPress bereiken.
- Beperk inlogpogingen: Plugins zoals Limit Login Attempts Reloaded voorkomen dat aanvallers geautomatiseerde wachtwoordrade-aanvallen uitvoeren.
- Schakel XML-RPC uit als u het niet nodig heeft: XML-RPC is een andere veelvoorkomende aanvalsvector voor brute force en DDoS-versterking.
Verifieer de wijzigingen met InspectWP
Voer na implementatie van deze wijzigingen een nieuwe InspectWP-scan uit op uw site. Controleer de WordPress-sectie van het rapport. Het versienummer mag niet meer in de HTML-broncode verschijnen en de meta-generator-tag moet verdwenen zijn. Als InspectWP nog steeds een versie detecteert, controleer dan dat het codefragment correct is geladen en dat cachingplugins geen verouderde versie van uw pagina's serveren.