De XML-RPC WordPress specificatie is ontwikkeld om communicatie tussen verschillende systemen te standaardiseren. Dat wil zeggen dat toepassingen buiten WordPress (bijvoorbeeld andere bloggingplatforms en desktopclients) met WordPress kunnen werken.

Deze specificatie is al onderdeel van WordPress sinds het begin en was altijd erg nuttig. WordPress had zonder dit systeem in een eigen koker gezeten, apart van alle andere internettoepassingen.

Maar xlmrpc.php heeft ook nadelen. Zo kan het kwetsbaarheden veroorzaken in je WordPress website, en is het inmiddels overbodig gemaakt door de WordPress REST API, die WordPress veel toegankelijker maakt voor andere toepassingen.

In dit artikel zullen we uitleggen wat xmlrpc.php is, waarom je het beter kunt uitschakelen, en we helpen je vast te stellen of het überhaupt actief is binnen je WordPress website.

Ben je er klaar voor? Laten er dan induiken!

Wat is xmlrpc.php?

XML-RPC is een specificatie die communicatie mogelijk maakt tussen WordPress en andere systemen. Dit gebeurt door deze communicatie te standaardiseren, waarbij HTTP als transportmechanisme wordt gebruikt en XML als coderingsmechanisme.

XML-RPC is ouder dan WordPress: het was namelijk al onderdeel van de b2 blogsoftware, waar WordPress zich van afsplitste in 2003. De code achter dit systeem is opgeslagen in een bestand dat xmlrpc.php heet, te vinden in de hoofdmap van de site. En daar kun je het nog altijd vinden, alhoewel XML-RPC allang achterhaald is.

In eerdere versies van WordPress was XML-RPC standaard uitgeschakeld. Echter, dit veranderde met versie 3.5. De belangrijkste reden hiervoor was om het mogelijk te maken dat je mobiele WordPress app kon communiceren met je WordPress installatie.

Als je de WordPress mobiele app gebruikte vóór versie 3.5, heb je wellicht wel eens XML-RPC in moeten schakelen op je website, voordat je content kon plaatsen vanuit de app. Dat was omdat de app niet WordPress zelf draaide, maar echt een aparte app was die met WordPress communiceerde via xmlrpc.php.

Maar XML-RPC wordt niet alleen gebruikt voor de mobiele app. Het maakt ook de communicatie tussen WordPress en andere blogplatforms mogelijk en zorgt ook dat trackbacks en pingbacks goed kunnen werken. Het was de techniek achter de Jetpack plugin, waarmee een zelf-gehoste WordPress website werd gelinkt aan WordPress.com.

Maar sinds de REST API werd geïntegreerd in de WordPress kern is het xmlrpc.php bestand niet langer nodig om deze dingen te bewerkstelligen. In plaats daarvan wordt de REST API gebruikt om te communiceren met de mobiele WordPress app, met desktop clients, andere blogplatforms, WordPress.com (voor de Jetpack plugin) en met andere systemen en diensten. De REST API kan communiceren met veel meer systemen dan xmlrpc.php. Het biedt ook meer flexibiliteit.

Omdat de REST API XML-RPC heeft vervangen, zou je tegenwoordig xmlrpc.php uit moeten zetten binnen je site. Laten we kijken waarom.

Waarom je xmlrpc.php beter kunt uitschakelen

De belangrijkste reden waarom je xmlrpc.php beter kan uitschakelen binnen je WordPress website, is omdat het zorgt voor kwetsbaarheden, die bij aanvallen gebruikt kunnen worden.

En aangezien je niet langer XML-RPC nodig hebt om te communiceren met systemen buiten WordPress, vervalt de noodzaak om het actief te houden. Daarom is het verstandig je website veiliger te maken door het gewoon uit te zetten.

Maar waarom is xmlrpc.php überhaupt nog onderdeel van WordPress, als het geen functie heeft en wel een veiligheidsrisico creëert?

Eén van de belangrijkste features van WordPress is dat het altijd compatibel is met oudere systemen. Als je je website goed beheert, zul je weten dat het up-to-date houden van WordPress en al je plugins en thema’s een essentiële taak is.

Maar er zullen altijd websitebeheerders zijn die hun WordPress versie niet kunnen of willen updaten. En ja, als ze een versie gebruiken die ouder is dan een versie met een REST API, hebben ze toegang nodig tot xmlrpc.php.

Laten we in detail naar de specifieke kwetsbaarheden kijken.

DDoS aanvallen via XML-RPC Pingbacks

Xmlrpc.php maakte pingbacks en trackbacks mogelijk. Dat zijn meldingen die verschijnen in de reacties op je website wanneer een andere blog of website naar je content linkt.

De XML-RPC specificatie maakte deze communicatie mogelijk, maar dit is nu dus vervangen door de REST API.

Wanneer XML-RPC ingeschakeld is op je website, zou een hacker een DDoS aanval kunnen uitvoeren op je website door xmlrpc.php te gebruiken om in korte tijd enorme aantallen pingbacks naar je website te sturen. Hierdoor kan je server overbelast raken, waardoor je website offline gaat.

Bruteforce-aanvallen via XML-RPC

Elke keer dat xmlrpc.php een verzoek doet, stuurt het de gebruikersnaam en wachtwoord mee ter controle. Dit creëert een niet mis te verstaan veiligheidsrisico. Dit is ook de reden dat de REST API dat dus ook niet doet. In plaats daarvan gebruikt de REST API OAuth, waarmee tokens worden gestuurd ter verificatie.

Omdat xmlrpc.php authenticatieve informatie verstuurt bij elk verzoek, kunnen hackers dit gebruiken om toegang tot je site te krijgen. Een brute-force aanval zou het zo mogelijk maken om content toe te voegen, code te verwijderen, en schade aan te richten in je database.

Stuurt een aanvaller genoeg verzoeken naar je site, elk met een andere combinatie van gebruikersnaam en wachtwoord, dan is er een kans dat ze toevallig op een gegeven moment de goede versturen en toegang krijgen.

Daarom moet je xmlrpc.php uitschakelen als je een up-to-date versie van WordPress met de REST API gebruikt. Deze verouderde methode is dan overbodig en maakt je website kwetsbaar.

Info

Alhoewel OAuth niet automatisch ondersteund wordt door Kinsta, kunnen klanten met een Enterprise pakket of hoger wel een implementatie aanvragen.

Draait xmlrpc.php op jouw WordPress website?

Het eerste dat je moet doen is vaststellen of jouw WordPress website xmlrpc.php gebruikt.

Het gaat er niet alleen om of het bestand te vinden is. Dat is namelijk onderdeel van elke WordPress installatie en zal dus ook te vinden zijn als XML-RPC uitgeschakeld is.

Maak eerst altijd een backup van je site voordat je iets verwijdert. In dit geval wil je xmlrpc.php niet simpelweg verwijderen, want dan zal je website crashen.

Gebruik in plaats daarvan de WordPress XML-RPC Validation Service om te kijken of xmlrpc.php ingeschakeld is. Deze service controleert je website en laat je zien of het wel of niet ingeschakeld is.

WordPress XML-RPC Validation Service

WordPress XML-RPC Validation Service

Dit is het resultaat dat ik kreeg toen ik deze site controleerde.

Kinsta XML-RPC check

Kinsta XML-RPC check

Dit laat zien dat xmlrpc.php inderdaad uitgeschakeld is op kinsta.com. Maar als je deze controle uitvoert en erachter komt dat xmlrpc.php nog ingeschakeld is, hoe zet je het dan uit?

Zo schakel je xmlrpc.php uit

Er zijn drie manieren om xmlrpc.php uit te schakelen:

We bekijken elke methode.

Schakel xmlrpc.php uit via een plugin

Het installeren van een plugin om xmlrpc.php uit te schakelen is verreweg de makkelijkste manier. De Disable XML-RPC plugin schakelt het helemaal uit, zoals de naam al doet vermoeden. Zo gebruik je de plugin.

Ik begin op mijn eigen website, waar ik nu xmlrpc.php heb ingeschakeld. Dit kun je zien in de controle:

Rachel McCollin website – XML-RPC check

Rachel McCollin website – XML-RPC check

Installeer de plugin via het venster Plugins binnen de WordPress admin, en activeer de plugin.

Klaar! Je hoeft verder niks te doen, het activeren van de plugin schakelt XML-RPC uit. Als ik nu weer de controle op mijn website uitvoer, krijg ik inderdaad een ander resultaat:

Rachel McCollin website – tweede XML-RPC check

Rachel McCollin website – tweede XML-RPC check

Lekker simpel dus.

Schakel XML-RPC pingbacks uit met een plugin

Maar wat als je alleen bepaalde aspecten van xmlrpc.php uit wilt schakelen? De Disable XML-RPC Pingback plugin schakelt alleen de pingbackfunctie uit, waardoor je nog altijd de andere features van XML-RPC kunt gebruiken indien nodig.

De plugin werkt op dezelfde manier als de Disable XML-RPC plugin: installeren, activeren, klaar.

Configureer de activering van XML-RPC en de REST API via een plugin

Als je meer precieze controle wilt over hoe zowel xmlrpc.php als de REST API werken binnen je website, dan kun je de REST XML-RPC Data Checker plugin installeren.

Na het installeren en activeren, ga je naar Instellingen > REST XML-RPC Data Checker en klik je op het tabblad XML-RPC.

REST XML-RPC Data Checker

REST XML-RPC Data Checker

Hiermee kun je precies instellen welke delen van xmlrpc.php actief moeten zijn op je site.

Ook kun je het alsnog helemaal uitschakelen. Wil je ook controle over de REST API, dan kun je dat doen met een ander tabblad binnen de plugin.

Heb je razendsnelle, veilige en ontwikkelaars-vriendelijke hosting nodig? Kinsta is gebouwd met WordPress developers in het achterhoofd en biedt een breed scala aan tools en een krachtig dashboard. Check hier onze pakketten

Schakel xmlrpc.php uit zonder plugin

Voeg je liever niet nog een plugin toe aan je website, dan kun je xmlrpc.php ook uitschakelen door wat code toe te voegen aan een filter, of aan je .htaccess bestand. Laten we beide methoden behandelen.

Schakel xmlrpc.php uit via een filter

De eerste optie is om het xmlrpc_enabled filter te gebruiken om xmlrpc.php uit te zetten. Voeg deze functie toe aan een plugin en activeer de plugin op je website:

add_filter( 'xmlrpc_enabled', '__return_false' );

Je zou dit stukje code bijvoorbeeld toe kunnen voegen aan het functions bestand van je thema, maar het is beter om een plugin te maken.

De andere optie is via het bewerken van je .htaccess bestand, wat mogelijk is bij hostingproviders die Apache gebruiken. Daarvoor maak je een verbinding met de server van je site via FTP of cPanel.

Info

Kinsta gebruikt Nginx webservers, waardoor je dus geen .htaccess bestand hebt. In plaats daarvan kun je tools gebruiken in je MyKinsta dashboard, waarmee je de belangrijkste .htaccess functies kunt gebruiken op een toegankelijke manier.

Schakel xmlrpc.php uit via het .htaccess bestand

Voeg de volgende code toe aan je .htaccess bestand:

<Files xmlrpc.php>
Order Allow,Deny
Deny from all
</Files>

Maak eerst een kopie voor je dit doet, al is het maar voor de zekerheid.

Vraag je hostingprovider om xmlrpc.php uit te schakelen

Sommige hostingprovider schakelen xmlrpc.php uit wanneer ze een aanval zien.

Bij Kinsta wordt er automatisch een stukje code toegevoegd aan het Nginx.config bestand als we een aanval via XML-RPC detecteren:

location ~* ^/xmlrpc.php$ {
return 403;
}

Dit resulteert in een 403 fout en dit stopt daarmee direct de aanval.

Als je dit zelf doet, kun je het beste een van de manieren hierboven proberen. Maar voordat je dat doet, kun je het beste altijd even vragen aan je hostingprovider wat hun maatregelen zijn.

Wanneer moet je xmlrpc.php juist wel inschakelen?

Er kunnen gevallen zijn waarin je xmlrpc.php (deels) moet inschakelen binnen je WordPress website.

Dit zijn:

En dat was het. Maar daarbij wil ik wel stellen: geen van bovenstaande redenen vind ik overtuigend genoeg om XML-RPC aan te laten staan.

De enige reden dat het nog altijd te vinden is in WordPress, is vanwege de backward compatibility, en je zou het dus alleen moeten gebruiken als je verouderde systemen gebruikt. Iedereen die websites up-to-date en modern wil houden, kan beter xmlrpc.php uitschakelen.

XML-RPC was ooit een essentieel onderdeel van WordPress. Nu is het een veiligheidsrisico.🔒 - Deze uitleg laat je precies zien hoe je het kunt uitschakelen 🚨.Click to Tweet

Samenvatting

De XML-RPC specificatie is nog eerder dan WordPress ontwikkeld, en werd gebruikt om WordPress te laten communiceren met externe systemen en toepassingen. Het heeft ingebouwde veiligheidsfouten en kan daardoor je website kwetsbaar maken voor aanvallen.

Nu de REST API de communicatie met andere toepassingen verzorgt, kun je xmlrpc.php rustig uitzetten. Volg de stappen hierboven om het uit te schakelen en zo de beveiliging van je website te verbeteren.


Als je dit artikel leuk vond, dan ga je Kinsta’s WordPress hosting platform ook heel erg leuk vinden! Of het nu gaat om het versnellen van je website of de 24/7 support van ons ervaren WordPress-team. Onze door Google Cloud aangedreven infrastructuur is gericht op automatische schaalbaarheid, prestaties en beveiliging. Laat ons jou het Kinsta verschil tonen! Bekijk onze pakketten