WordPress affiche son numéro de version par défaut à plusieurs endroits. En soi, il ne s'agit pas d'une vulnérabilité critique. Mais cela donne aux attaquants une longueur d'avance. Si quelqu'un sait que vous utilisez WordPress 6.2.1, il peut rechercher tous les exploits connus pour cette version précise et les essayer contre votre site. Supprimer les informations de version est une première étape simple qui rend les outils d'analyse automatisés moins efficaces.
Où WordPress expose le numéro de version
WordPress est étonnamment généreux quant à la révélation de la version qu'il utilise. Voici les endroits les plus courants où les attaquants (et toute personne consultant votre code source) peuvent le trouver :
- Balise meta generator : WordPress ajoute une balise
<meta name="generator" content="WordPress 6.x.x">dans la section<head>de chaque page. C'est l'endroit le plus évident, et elle apparaît à chaque chargement de page. - Flux RSS et Atom : Le flux RSS de votre site (généralement à
/feed/) contient un élément<generator>avec la chaîne complète de version de WordPress. De nombreux propriétaires de sites oublient totalement les flux, laissant ce vecteur ouvert. - Chaînes de requête des scripts et feuilles de style : WordPress ajoute
?ver=6.x.xaux URL des fichiers CSS et JavaScript lorsqu'il les met en file d'attente. Même si vous supprimez la balise meta, ce paramètre diffuse toujours votre version dans chaque requête d'asset. - Le fichier readme.html : WordPress est livré avec un fichier
readme.htmlà la racine. Ce fichier contient le numéro de version en clair et est accessible à toute personne connaissant l'URL. - Le fichier license.txt : Comme
readme.html, le fichierlicense.txtse trouve à la racine de WordPress et peut confirmer que le site utilise WordPress. - Le code source de la page de connexion : La page de connexion WordPress à
/wp-login.phpcharge des feuilles de style et des scripts avec des chaînes de requête de version, ce qui en fait une autre source d'informations de version. - Réponses de l'API REST : La racine de l'API REST de WordPress à
/wp-json/peut également révéler des détails de version dans ses en-têtes de réponse ou dans le corps.
Pourquoi masquer la version est important
Chaque version majeure de WordPress dispose d'un changelog public. Lorsqu'un correctif de sécurité est publié, la vulnérabilité qu'il corrige devient publique. Des bots automatisés explorent constamment le web à la recherche de sites qui utilisent encore l'ancienne version vulnérable. Si votre site annonce « WordPress 6.2.1 » et qu'une injection SQL critique a été corrigée dans la 6.2.2, votre site devient une cible dans les heures suivant la publication du correctif.
Masquer le numéro de version ne corrige pas la vulnérabilité elle-même. Cela supprime simplement un point de données que les attaquants utilisent pour prioriser leurs cibles. Pensez-y comme à retirer votre numéro de maison d'une liste de domiciles aux portes déverrouillées. La porte est peut-être toujours ouverte, mais au moins vous ne figurez pas sur la liste restreinte.
Supprimer la version du HTML et des flux
Ajoutez le code suivant dans le fichier functions.php de votre thème ou, mieux encore, dans une extension spécifique au site afin qu'il survive aux changements de thème :
// Supprimer la balise meta generator de l'en-tete HTML
remove_action('wp_head', 'wp_generator');
// Supprimer la version des flux RSS
add_filter('the_generator', '__return_empty_string');
// Supprimer la chaine de requete de version des scripts et 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);L'appel à remove_action retire la balise meta. Le filtre the_generator gère les flux RSS et Atom. Les deux filtres de loader suppriment le paramètre ?ver= de tous les assets mis en file d'attente. L'utilisation de la priorité 9999 garantit que ce code s'exécute après que les extensions et thèmes ont ajouté leurs propres scripts.
Supprimer readme.html et license.txt
Ces fichiers statiques se trouvent à la racine de WordPress et contiennent des informations de version. Supprimez-les :
rm /path/to/wordpress/readme.html
rm /path/to/wordpress/license.txtIl y a un piège : WordPress recrée ces fichiers lors des mises à jour du cœur. Vous avez deux options. Vous pouvez les supprimer manuellement après chaque mise à jour. Ou vous pouvez ajouter un petit script à votre processus de déploiement qui les retire automatiquement. Si vous utilisez WP-CLI, un hook post-mise à jour fonctionne très bien pour cela.
Approches basées sur des extensions
Si vous préférez ne pas modifier de fichiers de code, plusieurs extensions gèrent la suppression de la version pour vous. Les extensions de sécurité comme Wordfence, iThemes Security et All In One WP Security incluent toutes des options pour masquer la version de WordPress. Des options légères comme Meta Generator and Version Info Remover se concentrent spécifiquement sur cette tâche sans ajouter de surcharge supplémentaire.
Lors du choix d'une extension, assurez-vous qu'elle couvre tous les emplacements listés ci-dessus, et pas seulement la balise meta. Certaines extensions ne suppriment que la balise generator et laissent intactes les chaînes de requête des scripts.
La sécurité par l'obscurité ne suffit pas
Masquer votre version de WordPress est une bonne pratique, mais ce n'est pas une stratégie de sécurité à elle seule. Un attaquant déterminé peut toujours identifier votre version de WordPress par d'autres méthodes, par exemple en comparant le contenu des fichiers JavaScript du cœur ou en vérifiant la présence de fonctionnalités spécifiques introduites dans certaines versions.
Pour une véritable sécurité, vous devez combiner le masquage de la version avec les fondamentaux :
- Maintenir WordPress, les thèmes et les extensions à jour : C'est la mesure la plus importante que vous puissiez prendre. La plupart des piratages WordPress exploitent des vulnérabilités connues dans des logiciels obsolètes.
- Utiliser des mots de passe forts et l'authentification à deux facteurs : Les attaques par force brute contre
wp-login.phprestent l'un des vecteurs d'attaque les plus courants. - Installer un pare-feu d'application web (WAF) : Des services comme Cloudflare, Sucuri ou un WAF basé sur une extension peuvent bloquer les requêtes malveillantes avant qu'elles n'atteignent WordPress.
- Limiter les tentatives de connexion : Des extensions comme Limit Login Attempts Reloaded empêchent les attaquants d'exécuter des attaques automatisées de devinette de mot de passe.
- Désactiver XML-RPC si vous n'en avez pas besoin : XML-RPC est un autre vecteur d'attaque courant pour la force brute et l'amplification DDoS.
Vérifier les changements avec InspectWP
Après avoir mis en œuvre ces changements, lancez une nouvelle analyse InspectWP de votre site. Vérifiez la section WordPress du rapport. Le numéro de version ne devrait plus apparaître dans le code source HTML, et la balise meta generator devrait avoir disparu. Si InspectWP détecte toujours une version, vérifiez que le snippet de code est correctement chargé et que les extensions de cache ne servent pas une version obsolète de vos pages.