Inleiding
Dit artikel beschrijft de beveiligingsaspecten van WordPress voor ontwikkelaars. Dit aangezien externe ontwikkelaars zo’n 80% van de plugins en thema’s bouwen en dus enorm bijdragen aan zowel de groei maar ook de risico’s van websites in WordPress.
Het doel is om ontwikkelaars te informeren over verschillende beveiligingsmaatregelen die ze kunnen nemen om hun gebruikers, en dus de WordPress-sites te beschermen tegen aanvallen.
We bespreken onderwerpen zoals injectiepreventie, beheer van gebruikerssessies, bescherming tegen cross-site scripting (XSS), configuratiebeveiliging en meer.
We proberen handvaten te geven die ontwikkelaars kunnen gebruiken om de veiligheid van hun websites te waarborgen en de mogelijke risico’s van bekende kwetsbaarheden te vermijden.
Veel leesplezier!
Injectie’s tegenhouden
Er zijn een reeks functies en API’s beschikbaar in WordPress om ontwikkelaars te helpen ervoor te zorgen dat ongeautoriseerde code niet kan worden geïnjecteerd, en om hen te helpen gegevens te valideren en te zuiveren. Beste werkwijzen en documentatie zijn beschikbaar9 over hoe deze API’s te gebruiken om invoer- en uitvoergegevens in HTML, URL’s, HTTP-headers en bij interactie met de database en het bestandssysteem te beschermen, valideren of zuiveren. Beheerders kunnen ook het type bestanden dat kan worden geüpload verder beperken via filters.
Gebroken authenticatie en sessiebeheer
De WordPress-kernsoftware beheert gebruikersaccounts en authenticatie, en details zoals gebruikers-ID, naam en wachtwoord worden aan de serverzijde beheerd, evenals de authenticatiecookies. Wachtwoorden worden in de database beschermd met behulp van standaardzout- en strektechnieken. Bestaande sessies worden vernietigd bij het uitloggen voor versies van WordPress na 4.0.
Lees meer authenticatie- en sessiebeheer
Cross Site Scripting (XSS)
WordPress biedt een reeks functies die kunnen helpen om ervoor te zorgen dat door gebruikers geleverde gegevens veilig zijn10. Vertrouwde gebruikers, dat wil zeggen beheerders en redacteuren op een enkele WordPress-installatie, en netwerkbeheerders alleen in WordPress Multisite, kunnen ongefilterde HTML of JavaScript plaatsen zoals ze nodig hebben, bijvoorbeeld binnen een bericht of pagina. Onbetrouwbare gebruikers en door gebruikers ingediende inhoud worden standaard gefilterd om gevaarlijke entiteiten te verwijderen, met behulp van de KSES-bibliotheek via de wp_kses-functie.
Als voorbeeld, het WordPress-kernteam merkte voor de release van WordPress 2.3 op dat de functie the_search_query() door de meeste thema-auteurs verkeerd werd gebruikt, omdat ze de uitvoer van de functie niet ontsnapten voor gebruik in HTML. In een zeer zeldzaam geval van een lichte inbreuk op de achterwaartse compatibiliteit, werd de uitvoer van de functie in WordPress 2.3 gewijzigd om vooraf ontsnapt te zijn.
Lees meer over Cross Site Scripting
Onveilige directe objectverwijzing
WordPress biedt vaak directe objectverwijzingen, zoals unieke numerieke identificatoren van gebruikersaccounts of inhoud die beschikbaar zijn in de URL of formuliervelden. Hoewel deze identificatoren directe systeeminformatie onthullen, voorkomen de uitgebreide machtigingen en toegangscontrolesystemen van WordPress ongeautoriseerde verzoeken.
Lees meer over onveilige objectverwijzing
Beveiligingsfouten in configuratie
De meeste beveiligingsconfiguraties in WordPress zijn beperkt tot één geautoriseerde beheerder. Standaardinstellingen voor WordPress worden voortdurend geëvalueerd op het niveau van het kernontwikkelingsteam, en het WordPress-kernontwikkelingsteam biedt documentatie en beste werkwijzen om de beveiliging van serverconfiguratie voor het draaien van een WordPress-site11 te verbeteren.
Lees meer over beveiligingsfouten bij de configuratie
Blootstelling van gevoelige gegevens
Wachtwoorden van WordPress-gebruikersaccounts worden gezouten en gehasht op basis van het Portable PHP Password Hashing Framework12. Het machtigingssysteem van WordPress wordt gebruikt om toegang tot privé-informatie te regelen, zoals persoonlijk identificeerbare informatie (PII) van geregistreerde gebruikers, e-mailadressen van reageerders, privé gepubliceerde inhoud, enzovoort. In WordPress 3.7 werd een wachtwoordsterktemeter opgenomen in de kernsoftware, die extra informatie geeft aan gebruikers bij het instellen van hun wachtwoorden en hints geeft om de sterkte te vergroten. WordPress heeft ook een optionele configuratie-instelling voor het vereisen van HTTPS.
Lees meer over blootstelling van gevoelige gegevens
Ontbrekende controle op functieniveau
Voordat een actieverzoek wordt uitgevoerd, controleert WordPress op de juiste autorisatie en machtigingen voor verzoeken op functieniveau. Toegang of visualisatie van administratieve URL’s, menu’s en pagina’s zonder de juiste authenticatie is nauw geïntegreerd met het authenticatiesysteem om toegang door ongeautoriseerde gebruikers te voorkomen.
Lees meer over ontbrekende controles op functieniveau’s
Cross Site Request Forgery (CSRF)
WordPress gebruikt cryptografische tokens, zogenaamde “nonces”13, om de intentie van actieverzoeken van geautoriseerde gebruikers te valideren en te beschermen tegen mogelijke CSRF-bedreigingen. WordPress biedt een API voor het genereren van deze tokens om unieke en tijdelijke tokens te maken en te verifiëren, en het token is beperkt tot een specifieke gebruiker, een specifieke actie, een specifiek object en een specifieke tijdsperiode, die indien nodig aan formulieren en URL’s kunnen worden toegevoegd. Bovendien worden alle nonces ongeldig gemaakt bij het uitloggen.
Gebruik van componenten met bekende kwetsbaarheden
Het WordPress-kernontwikkelingsteam houdt nauwlettend toezicht op de weinige meegeleverde bibliotheken en kaders waarmee WordPress integreert voor kernfunctionaliteit. In het verleden heeft het kernontwikkelingsteam bijgedragen aan verschillende externe componenten om ze veiliger te maken, zoals de update om een cross-site-kwetsbaarheid in TinyMCE te herstellen in WordPress 3.5.214.
Indien nodig kan het kernontwikkelingsteam besluiten kritieke externe componenten af te splitsen of te vervangen, zoals toen de SWFUpload-bibliotheek officieel werd vervangen door de Plupload-bibliotheek in 3.5.2, en een veilige afsplitsing van SWFUpload beschikbaar werd gesteld door het beveiligingsteam15 voor de plug-ins die SWFUpload op korte termijn bleven gebruiken.
Niet-gevalideerde omleidingen en doorsturingen Het interne toegangscontrole- en authenticatiesysteem van WordPress beschermt tegen pogingen om gebruikers naar ongewenste bestemmingen te leiden of automatische omleidingen te maken. Deze functionaliteit is ook beschikbaar gesteld aan plug-in ontwikkelaars via een API, wp_safe_redirect()16.
Verdere beveiligingsrisico’s en zorgen XXE (XML eXternal Entity) verwerkingsaanvallen Bij het verwerken van XML schakelt WordPress het laden van aangepaste XML-entiteiten uit om zowel externe entiteits- als entiteitsuitbreidingsaanvallen te voorkomen. Naast de kernfunctionaliteit van PHP biedt WordPress geen aanvullende beveiligde XML-verwerkings-API voor plug-in auteurs.
SSRF (Server Side Request Forgery) aanvallen HTTP-verzoeken die door WordPress worden verzonden, worden gefilterd om toegang tot loopback- en privé-IP-adressen te voorkomen. Bovendien is toegang alleen toegestaan tot bepaalde standaard HTTP-poorten.