WordPress & rechten bij het updaten van themes, plugins en de WordPress core

Eerder deze week beschreef ik mijn eerste stappen in de dubbele rol van WordPressbeheerder en systeembeheerder. En vooral over de beveiligingsuitdagingen die daarbij komen kijken. Specifiek ging ik in op de concessies die ik moest maken om afbeeldingen en andere attachments toe te kunnen voegen aan mijn posts. In dit artikel ga ik dieper in op manieren waarop WordPress, plugins en themes veilig geüpdated kunnen worden.

Om het veilig implementeren van updates goed te begrijpen is het belangrijk iets van de rechtenstructuur te kennen. Uit het vorige artikel:

De uitdaging

Als WordPress-beheerder zijn de belangen anders. Dan moet het snel, efficiënt en zonder onnodige formulieren en vertragingen werken.

Als serverbeheerder wil je WordPress zo veel mogelijk onmogelijk maken iets zelfstandig uit te voeren op de server. Want de kans dat het mis gaat is groot.

Waarom is dat zo moeilijk?

Twee kapteins op één schip?

Op mijn server heb ik een eigen gebruiker: arne. Met deze gebruiker kan ik inloggen via ssh en sftp en kan ik alle web-content bewerken. Dat is wel zo veilig en er kan minder mis gaan.

Maar mijn websites (specifieker gezegd php) draait onder systeemgebruiker www-data. Om te zorgen dat mijn website toch getoond kan worden delen ze een groep. Php mag dus alle bestanden in mijn document-root lezen en gebruiken.

Waarom kan WordPress zichzelf niet updaten?

Een van de handige features van WordPress is dat het zichzelf kan updaten naar de meest recente versie. Zo kan elke willekeurige bezoeker bijdragen aan het up-to-date houden van plugins, themes en de WordPress core. Ook is het installeren van themes en plugins enorm makkelijk. Klikken op “install” start de installatie.

Vanuit de systeembeheer-rol word ik hier echter minder blij van. WordPress heeft hiervoor voldoende rechten nodig om bestanden te overschrijven en naar hartelust aan te passen. Hier is geen tussenkomst van de beheerder of kennishouder vereist. Ongeteste code, nieuwe functionaliteiten en mogelijke beveiligingsfouten worden zonder extra toelichting geïnstalleerd.

Daarom werk ik als systeembeheerder het automatisch updatebeleid tegen: ik ken WordPress niet de rechten toe zichzelf aan te passen. Dit zorgt er voor dat er enkel nieuwe code op de server wordt geschreven als ik hier expliciet toestemming voor geef. En dus dat elke wijziging onder toezicht wordt uitgevoerd.

Maar Mike, dat is fantastisch!

WordPress zal bij het installeren van een plugin, theme of het updaten van zichzelf een aantal checks uitvoeren. Op het moment dat WordPress zichzelf niet kan updaten zal het aanbieden dit via FTP, FTP via SSL of SSH te doen.

Wordpress installatie- en updateopties

Als de server nog niet voorzien is van libssh2-php zal de SSH2 optie nog niet getoond worden. Voor veel servers is dit de meest veilige manier van updaten. Daarom is het aan te raden deze te installeren (beheersrechten vereist):

$ sudo apt-get install libssh2-php

Waarom is dit fijn?

Bij het installeren van een plugin, theme of updaten van de WordPress-core zal er vanuit deze interface een SSH2 verbinding worden opgezet naar de server. Hierbij zijn twee zaken heel erg van belang.

1. Kies de gebruiker

Bij het maken van de verbinding moet een gebruiker worden opgegeven. Hier kies ik bewust voor de systeemgebruiker arne. Dit zorgt ervoor dat alle bestanden die geplaatst worden de rechten van deze gebruiker zullen aanhouden. Het behoudt de situatie dat WordPress zonder expliciete toestemming de eigen code niet kan overschrijven.

2. Het wachtwoord moet worden ingevuld

Het SSH wachtwoord wordt niet binnen WordPress opgeslagen. Dat houdt in dat als er op enig moment toch ongewenste toegang tot het systeem wordt verkregen, niet direct de shell-toegang tot de server is gecompromitteerd.

Conclusie

Waar in het vorige artikel een workaround voor schrijfrechten van WordPress binnen zichzelf oogluikend wordt toegelaten voor uploads, laat ik met dit artikel zien dat hetzelfde niet nodig is voor het veilig updaten van WordPress zelf. Ook plugins en themes laten zich prima installeren.

De uitzondering bestaat altijd dat een plugin of theme schrijfrechten vereist in een andere map dan /uploads. Hier kan de afweging gemaakt worden om schrijfrechten uit te delen of de beschrijfbare map te verplaatsen naar /wp-content/uploads.

Lees het dossier WordPress.

Dit artikel verscheen ook op True.nl/Blog