La spécification XML-RPC WordPress a été développée pour normaliser la communication entre différents systèmes, ce qui signifie que des applications extérieures à WordPress (telles que d’autres plateformes de blog et des clients d’ordinateurs de bureau) peuvent interagir avec WordPress.
Cette spécification fait partie de WordPress depuis sa création et a fait un travail très utile. Sans elle, WordPress aurait été dans son propre silo, séparé du reste de l’internet.
Cependant, le xmlrpc.php a ses inconvénients. Il peut introduire des vulnérabilités sur votre site WordPress et a été remplacé par l’API REST de WordPress, qui permet d’ouvrir beaucoup mieux WordPress à d’autres applications.
Dans cet article, nous allons expliquer ce qu’est le xmlrpc.php, pourquoi vous devriez le désactiver, et vous aider à déterminer s’il fonctionne sur votre site WordPress.
Prêts ? Plongeons !
Qu’est-ce que le xmlrpc.php ?
XML-RPC est une spécification qui permet la communication entre WordPress et d’autres systèmes. Pour ce faire, elle a normalisé ces communications, en utilisant HTTP comme mécanisme de transport et XML comme mécanisme de codage.
Le XML-RPC est antérieur à WordPress : il était présent dans le logiciel de blogging b2, qui a été forké pour créer WordPress en 2003. Le code à l’origine du système est stocké dans un fichier appelé xmlrpc.php, dans le répertoire racine du site. Et il est toujours là, même si XML-RPC est largement dépassé.
Dans les premières versions de WordPress, le XML-RPC était désactivé par défaut. Mais depuis la version 3.5, il est activé par défaut. La principale raison en était de permettre à l’application mobile de WordPress de communiquer avec votre installation WordPress.
Si vous utilisiez l’application mobile WordPress avant la version 3.5, vous vous souvenez peut-être d’avoir dû activer le XML-RPC sur votre site pour que l’application puisse afficher du contenu. En effet, l’application n’exécutait pas WordPress lui-même, mais était une application distincte communiquant avec votre site WordPress à l’aide du xmlrpc.php.
Mais le XML-RPC n’a pas été utilisé uniquement pour l’application mobile : il a également permis la communication entre WordPress et d’autres plateformes de blogs, il a permis les trackbacks et pingbacks, et il a alimenté l’extension Jetpack qui relie un site WordPress auto-hébergé à WordPress.com.
Mais depuis que l’API REST a été intégrée dans le noyau de WordPress, le fichier xmlrpc.php n’est plus utilisé pour cette communication. À la place, l’API REST est utilisée pour communiquer avec l’application mobile WordPress, avec les clients d’ordinateurs de bureau, avec d’autres plateformes de blogs, avec WordPress.com (pour l’extension Jetpack) et avec d’autres systèmes et services. L’éventail des systèmes avec lesquels l’API REST peut interagir est beaucoup plus large que celui autorisé par le xmlrpc.php. La flexibilité est également beaucoup plus grande.
Comme l’API REST a remplacé XML-RPC, vous devez maintenant désactiver le xmlrpc.php sur votre site. Voyons pourquoi.
Pourquoi vous devriez désactiver le xmlrpc.php
La principale raison pour laquelle vous devriez désactiver le xmlrpc.php sur votre site WordPress est qu’il introduit des vulnérabilités de sécurité et peut être la cible d’attaques.
Maintenant que le XML-RPC n’est plus nécessaire pour communiquer en dehors de WordPress, il n’y a plus de raison de le maintenir actif. C’est pourquoi il est judicieux de rendre votre site plus sûr en le désactivant.
Si le xmlrpc.php est un problème de sécurité et qu’il ne fonctionne plus, pourquoi n’a-t-il pas été complètement supprimé de WordPress ?
La raison en est que l’une des principales caractéristiques de WordPress sera toujours la rétrocompatibilité. Si vous gérez bien votre site, vous savez qu’il est essentiel de maintenir WordPress à jour, ainsi que toutes les extensions ou thèmes.
Mais il y aura toujours des propriétaires de sites web qui ne voudront ou ne pourront pas mettre à jour leur version de WordPress. S’ils utilisent une version antérieure à l’API REST, ils devront toujours avoir accès au xmlrpc.php.
Examinons plus en détail les vulnérabilités spécifiques.
Attaques DDoS via les pingbacks XML-RPC
L’une des fonctions que le xmlrpc.php permettait d’activer était les pingbacks et les trackbacks. Ce sont les notifications qui apparaissent dans les commentaires de votre site lorsqu’un autre blog ou site renvoie à votre contenu.
C’est la spécification XML-RPC qui a rendu cette communication possible, mais elle a été remplacée par l’API REST (comme nous l’avons déjà vu).
Si le XML-RPC est activé sur votre site, un pirate pourrait potentiellement monter une attaque DDoS sur votre site en exploitant le xmlrpc.php pour envoyer un grand nombre de pingbacks sur votre site en peu de temps. Cela pourrait surcharger votre serveur et mettre votre site hors service.
Attaques de force brute via XML-RPC
Chaque fois que le xmlrpc.php fait une requête, il envoie l’identifiant et le mot de passe pour l’authentification. Cela représente une responsabilité importante en matière de sécurité et c’est quelque chose que l’API REST ne fait pas. En fait, l’API REST utilise OAuth qui envoie des jetons pour l’authentification au lieu d’identifiants ou de mots de passe.
Comme le xmlrpc.php envoie des informations d’authentification avec chaque requête, les pirates pourraient les utiliser pour tenter d’accéder à votre site. Une attaque de force brute comme celle-ci pourrait leur permettre d’insérer du contenu, de supprimer du code ou d’endommager votre base de données.
Si un attaquant envoie suffisamment de requêtes à votre site, chacune avec une paire d’identifiant et de mots de passe différente, il y a une chance qu’il puisse éventuellement trouver la bonne, lui donnant ainsi accès à votre site.
C’est pourquoi, si vous utilisez une version à jour de WordPress, qui utilise l’API REST pour communiquer avec des systèmes externes, vous devez désactiver le xmlrpc.php. Ce n’est pas nécessaire et cela pourrait rendre votre site vulnérable.
Est-ce que le xmlrpc.php fonctionne sur votre site WordPress ?
La première chose à faire est d’identifier si le xmlrpc.php fonctionne sur votre site WordPress.
Il ne s’agit pas simplement de vérifier si le fichier est là : il fait partie de chaque installation de WordPress et sera présent même si XML-RPC est désactivé.
Pour vérifier si xmlrpc.php est activé sur votre site, utilisez l’application web du validateur XML-RPC. Celui-ci vérifiera votre site et vous indiquera si le xmlrpc.php est activé.
Cela montre que xmlrpc.php a été désactivé sur kinsta.com. Donc, si vous effectuez la vérification et découvrez que le xmlrpc.php est toujours activé sur votre site, comment le désactiver ?
Comment désactiver le xmlrpc.php
Il y a trois façons de désactiver le xmlrpc.php :
Examinons chacun d’entre eux individuellement.
Comment désactiver le xmlrpc.php avec une extension
L’installation d’une extension pour désactiver le xmlrpc.php est la façon la plus simple de procéder. L’extension Disable XML-RPC le désactivera complètement. Voici comment l’utiliser.
Mon point de départ est mon propre site web, sur lequel le xmlrpc.php est activé. Vous pouvez le voir grâce à la vérification que j’ai faite :
Installez l’extension via votre des extensions dans l’administration de WordPress, et activez-la.
Vous n’avez rien d’autre à faire : l’activation de l’extension entraînera la désactivation de XML-RPC. Maintenant, si je fais une vérification sur mon site, j’obtiens un résultat différent :
C’est aussi simple que cela !
Désactiver les pingbacks XML-RPC avec une extension
Mais que faire si vous voulez désactiver certains aspects du xmlrpc.php et pas d’autres ? L’extension Disable XML-RPC Pingback vous permet de désactiver uniquement la fonctionnalité de pingback, ce qui signifie que vous avez toujours accès aux autres fonctionnalités de XML-RPC si vous en avez besoin.
L’extension fonctionne de la même manière que l’extension Disable XML-RPC : il suffit de l’installer, de l’activer et elle fonctionnera.
Configurer l’activation des API XML-RPC et REST avec une extension
Si vous souhaitez un contrôle plus précis de la configuration du xmlrpc.php et de l’API REST sur votre site, vous pouvez installer l’extension REST XML-RPC Data Checker.
Une fois que vous avez installé et activé cette extension, allez dans Réglages > REST XML-RPC Data Checker et cliquez sur l’onglet XML-RPC.
Cela vous permet de configurer exactement quels aspects de xmlrpc.php sont actifs sur votre site.
Vous pouvez aussi tout simplement l’éteindre. Et si vous voulez également contrôler l’API REST, l’extension vous donne un autre onglet pour cela.
Comment désactiver le xmlrpc.php sans extension
Si vous préférez ne pas installer une autre extension sur votre site, vous pouvez désactiver le xmlrpc.php en ajoutant du code dans un filtre, ou dans votre fichier .htaccess. Examinons ces deux méthodes.
Désactiver le xmlrpc.php via un filtre
Une option consiste à utiliser le filtre xmlrpc_enabled pour désactiver le xmlrpc.php. Ajoutez cette fonction à une extension et activez-la sur votre site :
add_filter( 'xmlrpc_enabled', '__return_false' );Vous pouvez l’ajouter à votre fichier de fonctions de thème, mais il est préférable d’écrire une extension.
L’autre option consiste à modifier votre fichier .htaccess, disponible chez les hébergeurs qui utilisent Apache, en vous connectant au serveur de votre site via FTP ou cPanel.
Désactiver le xmlrpc.php via le fichier .htacess
Dans votre fichier .htaccess, ajoutez ce code :
<Files "xmlrpc.php">
Require all denied
</Files>Veillez à faire une copie de l’ancien fichier avant de faire cela, au cas où vous auriez des problèmes.
Demander à votre hébergeur de désactiver le xmlrpc.php
Par ailleurs, certains hébergeurs désactiveront le xmlrpc.php si une attaque est détectée.
Cela produira une erreur 403 et arrêtera l’attaque sur sa lancée.
Chez Kinsta, il n’y a pas besoin de s’inquiéter, ceci est déjà bloqué. Contactez le support pour tout problème.
Si vous le faites vous-même, il est préférable d’utiliser l’une des méthodes ci-dessus. Mais avant cela, vérifiez toujours auprès de votre hébergeur.
Quand devez-vous activer le xmlrpc.php ?
Il peut arriver que vous deviez activer le xmlrpc.php sur votre site WordPress ou que vous ne deviez pas le désactiver complètement.
C’est le cas quand :
- Vous n’utilisez pas l’API REST (non conseillée, mais nécessaire dans certaines situations) mais vous devez faire communiquer votre site WordPress avec d’autres systèmes.
- Vous ne pouvez pas mettre à jour WordPress à la version 4.4 ou supérieure, et n’avez donc pas accès à l’API REST. Cela peut être dû à des restrictions dans votre configuration d’hébergement (auquel cas je changerais d’hébergeur) ou à une incompatibilité de thème ou d’extensions (auquel cas je les remplacerais ou les mettrais à jour).
- Vous travaillez avec une application externe qui ne peut pas accéder à l’API REST WP mais qui peut accéder à XML-RPC (à long terme, je vous conseille de mettre à jour cette application ou de passer à une application compatible REST).
C’est tout ! Aucune de ces raisons n’est particulièrement valable pour maintenir la spécification XML-RPC activée.
La seule raison pour laquelle elle est toujours dans WordPress est la retrocompatibilité et vous ne l’utiliserez que si vous travaillez avec des systèmes obsolètes. Pour tous ceux qui souhaitent maintenir leurs sites à jour et travailler avec les dernières technologies, la désactivation du xmlrpc.php est la solution.
Résumé
La spécification du XML-RPC a été développée avant même la création de WordPress, comme moyen pour WordPress de communiquer avec des systèmes et des applications externes. Elle présente des failles de sécurité inhérentes et pourrait rendre votre site vulnérable aux attaques.
Maintenant que l’API REST permet à votre site de communiquer avec d’autres applications, vous pouvez désactiver le xmlrpc.php en toute sécurité. Si vous suivez les étapes ci-dessus, en le désactivant, vous améliorerez la sécurité de votre site.
Rachel McCollin has been helping people build websites with WordPress since 2010. She's a huge fan of self-hosted WordPress and wants to help as many people as possible create an awesome website with it.
Laisser un commentaire