XML-RPC is van oorsprong een algemeen protocol: een programma stuurt een XML-verzoek met de naam van een methode en de parameters, de server voert die uit en antwoordt in XML. In WordPress heeft het de vorm van het bestand xmlrpc.php, in de root van de site. Het stamt uit de tijd dat je artikelen in een desktopprogramma schreef, en het ondersteunt naast de eigen wp.*-methoden van WordPress ook de oude API's van Blogger, metaWeblog en Movable Type.
Waar XML-RPC vandaag nog voor dient
- Publiceren op afstand vanuit een app of externe tool die inlogt met een gebruikersnaam en wachtwoord.
- Pingbacks ontvangen, de meldingen die een ander blog stuurt wanneer het naar je verwijst (methode
pingback.ping). - Bepaalde diensten laten werken, met name Jetpack, waarvan de koppeling met WordPress.com via
xmlrpc.phploopt.
Sinds de REST API in de core zit, is er voor de meeste van die behoeften een modernere oplossing. Veel sites gebruiken XML-RPC helemaal niet meer, terwijl het standaard actief blijft.
De risico's
De officiële documentatie van WordPress noemt xmlrpc.php een veelvoorkomend doelwit van brute force: elke publicatie-aanroep accepteert een gebruikersnaam en wachtwoord, zonder dat er een pagina geladen of een cookie gezet hoeft te worden. In oktober 2015 beschreef Sucuri aanvallen die de methode system.multicall gebruikten om honderden wachtwoorden in een enkel HTTP-verzoek te testen. WordPress 4.4 heeft die versterking beperkt: na een mislukte authenticatie mislukken de volgende aanroepen in hetzelfde verzoek ook. De methode blijft echter een bron van serverbelasting en een veelvoorkomende reden voor blokkades op firewallniveau.
Pingbacks zorgen voor een ander probleem. Om een pingback te controleren, haalt WordPress de pagina op die zegt ernaar te verwijzen, op een adres dat de afzender zelf opgeeft. Zo kunnen duizenden sites, zonder gehackt te zijn, als doorgeefluik dienen voor een DDoS-aanval op hetzelfde slachtoffer.
Voor WordPress: XML-RPC afsluiten of beperken
Een punt dat vaak verkeerd wordt begrepen: het filter xmlrpc_enabled schakelt XML-RPC niet uit. Volgens de documentatie zet het alleen de methoden uit die authenticatie vereisen, niet de pingbacks. Afhankelijk van je gebruik:
- Geen gebruik: blokkeer
xmlrpc.phpop server- of CDN-niveau (blok<Files "xmlrpc.php">onder Apache,location = /xmlrpc.php { deny all; }onder Nginx). Alleen zo voorkom je ook dat PHP wordt belast. - Jetpack: dezelfde blokkade, met een uitzondering voor de IP-adressen die Jetpack publiceert.
- Publiceren op afstand: laat het bestand staan, verwijder
pingback.pingvia het filterxmlrpc_methodsen gebruik applicatiewachtwoorden, die je per stuk kunt intrekken.
Open na de wijziging /xmlrpc.php in een privévenster: het antwoord moet 403 of 404 zijn. Ons artikel XML-RPC in WordPress: risico's, gebruik en uitschakelen vergelijkt de methoden in detail. Houd je XML-RPC aan, dan maakt tweefactorauthenticatie op de accounts die publiceren gestolen wachtwoorden een stuk minder bruikbaar.
De module Hardening van WP Masquerade pakt XML-RPC al in de gratis versie aan: een eerste niveau verwijdert de pingbackmethoden, het volgende laat xmlrpc.php antwoorden met een 404-fout, met de waarschuwing dat Jetpack en sommige apps dan niet meer werken. Omdat WordPress zelf blokkeert, wordt PHP nog steeds aangesproken: een server- of CDN-regel haalt ook die belasting weg. Verzoeken naar het afgesloten adres worden geteld als robotval.