XML-RPC is een van die WordPress-functies waarvan de meeste site-eigenaren nog nooit hebben gehoord — en toch draait het al meer dan tien jaar stilletjes op de achtergrond van vrijwel elke WordPress-installatie. Het bestand xmlrpc.php staat in de hoofdmap en accepteert verzoeken van buitenaf. Oorspronkelijk was het de enige manier om een WordPress-blog op afstand te beheren. Tegenwoordig is het vooral een beveiligingsrisico dat aanvallers graag uitbuiten.
Wat XML-RPC daadwerkelijk doet
XML-RPC staat voor Extensible Markup Language – Remote Procedure Call. Eenvoudig gezegd is het een manier voor externe software om via HTTP met uw WordPress-site te communiceren. De externe applicatie verstuurt een speciaal opgemaakt XML-verzoek naar uwsite.com/xmlrpc.php, WordPress verwerkt het en geeft een XML-respons terug.
Via deze interface kunnen externe clients zaken doen zoals:
- Berichten en pagina's aanmaken, bewerken en verwijderen
- Afbeeldingen en andere media uploaden
- Reacties modereren en beheren
- Siteconfiguratie en metadata ophalen
- Pingbacks tussen blogs verzenden en ontvangen
Beschouw het als een primitieve API — functioneel, maar ontworpen in een tijdperk vóór REST API gangbaar was.
Een stukje geschiedenis
Halverwege de jaren 2000 was XML-RPC uw enige optie als u een blogbericht wilde schrijven vanaf uw telefoon of een desktop-app zoals Windows Live Writer. WordPress nam de MetaWeblog API en de Blogger API over, beide gebaseerd op XML-RPC, om deze tools met uw site te laten communiceren.
In 2016 kwam WordPress 4.7 uit met de REST API ingebouwd. Plotseling was er een moderne, gestandaardiseerde manier om met WordPress te communiceren — een die JSON gebruikt in plaats van XML, fatsoenlijke authenticatie ondersteunt en veel gemakkelijker te gebruiken is. Vanaf dat moment werd XML-RPC een relikwie. De meeste moderne plugins, apps en integraties gebruiken uitsluitend de REST API.
Waarom XML-RPC een beveiligingsprobleem is
Het bestand is standaard publiek toegankelijk op elke WordPress-site. Alleen al dat is niet ideaal, maar de echte problemen zitten dieper:
- Brute-force-versterking — XML-RPC heeft een methode genaamd
system.multicallwaarmee u honderden verzoeken in één bundelt. Een aanvaller kan 500 gebruikersnaam-wachtwoordcombinaties testen in één enkel HTTP-verzoek. Veel logininbeveiligingsplugins zien dit niet eens gebeuren omdat ze alleenwp-login.phpin de gaten houden. - Misbruik van pingbacks — De pingback-functie kan worden ingezet voor DDoS-aanvallen. Een aanvaller laat duizenden WordPress-sites een doelserver "pingen", waardoor onschuldige sites in feite een botnet worden. Dit is in de praktijk herhaaldelijk voorgekomen.
- Gebruikersnaam-enumeratie — Zelfs zonder geldige inloggegevens kunnen XML-RPC-responsen bevestigen of een gebruikersnaam bestaat, waarmee aanvallers de helft van de informatie krijgen die ze nodig hebben.
- Onnodig aanvalsoppervlak — Elk publiek toegankelijk eindpunt dat authenticatie accepteert, is een potentiële toegangsroute. Als u XML-RPC niet gebruikt, is het openhouden ervan als een onvergrendelde deur die nooit wordt gebruikt.
Wie heeft het echt nog nodig?
Het eerlijke antwoord: vrijwel niemand. Er zijn enkele uitzonderingen:
- Jetpack leunde vroeger zwaar op XML-RPC, maar is overgestapt op de REST API. Nieuwere Jetpack-versies werken zonder XML-RPC voor de meeste functies.
- Zeer oude mobiele apps — De huidige WordPress-mobiele app gebruikt de REST API. Alleen verouderde versies van vóór 2016 hebben XML-RPC nog nodig.
- Verouderde tools van derden — Sommige oeroude IFTTT-recepten of publicatieplatforms gebruiken het misschien nog, maar voor alle daarvan bestaan alternatieven.
Als geen van deze op u van toepassing is, is er geen goede reden om XML-RPC ingeschakeld te laten.
Hoe u XML-RPC uitschakelt
De snelste methode is een filter in functions.php van uw thema of een aangepaste plugin:
add_filter('xmlrpc_enabled', '__return_false');Hiermee worden de XML-RPC-methoden uitgeschakeld, maar het bestand geeft nog steeds een respons. Om de toegang volledig op serverniveau te blokkeren, voegt u dit toe aan uw .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Of als u Nginx gebruikt:
location = /xmlrpc.php {
deny all;
return 403;
}Veel beveiligingsplugins (Wordfence, iThemes Security, Sucuri) bieden ook een schakelaar om XML-RPC met één klik uit te schakelen.
Hoe InspectWP helpt
InspectWP controleert of uw xmlrpc.php-eindpunt van buitenaf bereikbaar is. Als het op verzoeken reageert, markeert het rapport dit en legt uit waarom u zou moeten overwegen het uit te schakelen — zeker als uw site geen legitieme reden heeft om het actief te houden.