Beveiliging

Leer meer over WordPress core software security in dit gratis white paper. Je kunt het ook downloaden in PDF formaat.

Overzicht

Dit document is een analyse en uitleg van de core software-ontwikkeling van WordPress en de bijbehorende beveiligingsprocessen, evenals een onderzoek van de inherente beveiliging die rechtstreeks in de software is ingebouwd. Beslissers die WordPress evalueren als een contentmanagementsysteem of web-applicatie zouden dit document moeten gebruiken in hun analyse en besluitvorming, en voor ontwikkelaars om ernaar te verwijzen om zich vertrouwd te maken met de beveiligingscomponenten en best practices van de software.

De informatie in dit document is up-to-date voor de nieuwste stabiele release van de software, WordPress 4.7 op het moment van publicatie, maar moet ook als relevant worden beschouwd voor de meest recente versies van de software, omdat compatibiliteit met eerdere versies een sterke focus is voor het WordPress ontwikkelingsteam. Specifieke beveiligingsmaatregelen en wijzigingen worden genoteerd, omdat deze in specifieke releases aan de core software zijn toegevoegd. Het wordt ten zeerste aangeraden om altijd de laatste stabiele versie van WordPress te gebruiken om de meest veilige ervaring mogelijk te maken.

Samenvatting

WordPress is een dynamisch open source contentbeheersysteem waar miljoenen websites, web-applicaties en blogs op draaien. Het wordt momenteel door meer dan35% van de top 10 miljoen websites op internet gebruikt. De bruikbaarheid, uitbreidbaarheid en volwassen ontwikkeling van WordPress maken het een populaire en veilige keuze voor websites van elke omvang.

Sinds de start in 2003 heeft WordPress een voortdurende verharding ondergaan, zodat zijn core software veel voorkomende beveiligingsrisico's kan aanpakken en beperken, waaronder de Top 10-lijst die is geïdentificeerd door het Open Web Application Security Project (OWASP) als veelvoorkomende beveiligingskwetsbaarheden, welke in dit document worden besproken .

Het WordPress Security Team, in samenwerking met het WordPress Core Leadership Team en ondersteund door de wereldwijde WordPress-community, werkt aan het identificeren en oplossen van beveiligingsproblemen in de core software die beschikbaar is voor distributie en installatie op WordPress.org. Daarnaast bevelen ze de aan en documenteren ze beste beveiligingsoplossingen en werkwijze voor plugin- en themabouwers van derde partijen .

Siteontwikkelaars en beheerders moeten bijzondere aandacht besteden aan het juiste gebruik van de hoofd API's en de onderliggende serverconfiguratie, welke de oorzaak zijn van veelvoorkomende kwetsbaarheden, als ook ervoor te zorgen dat alle gebruikers sterke wachtwoorden gebruiken om toegang te krijgen tot WordPress.

Een overzicht van WordPress

WordPress is een gratis en open source content managementsysteem (CMS). Het is de meest gebruikte CMS-software ter wereld en draait op meer dan 35% van de top 10 miljoen websites1, en heeft daarmee een geschat 62% marktaandeel van alle sites die met een CMS gemaakt zijn.

WordPress is gelicenseerd onder de General Public License (GPLv2 of later), die vier kernvrijheden biedt en kan worden beschouwd als de WordPress “ bill of rights ”:

  1. De vrijheid om het programma te draaien voor welk doen dan ook.
  2. De vrijheid om het programme te bestuden en aan te passen zodat het doet wat jij wilt.
  3. De vrijheid om te herdistribueren.
  4. De vrijheid om kopies van jouw aangepaste versies te verspreiden naar anderen.

Het WordPress Core Leadership Team

Het WordPress-project is een meritocratie, geleid door een core leadership team en geleid door zijn mede-schepper en hoofdontwikkelaar, Matt Mullenweg. Het team beheert alle aspecten van het project, inclusief core-ontwikkeling, WordPress.org en gemeenschapsinitiatieven.

Het Core Leadership Team bestaat uit Matt Mullenweg, vijf hoofdontwikkelaars en meer dan twaalf core-ontwikkelaars met permanente commit-toegang. Deze ontwikkelaars hebben de uiteindelijke autoriteit over technische beslissingen en leiden architectuurdiscussies en implementatie-inspanningen.

WordPress heeft een aantal bijdragende ontwikkelaars. Sommige hiervan zijn voormalige of huidige committers, en sommige zijn mnogelijk toekomstige committers. Deze bijdragende ontwikkelaars zijn vertrouwde en ervaren bijdragers aan WordPress die veel respect hebben verdiend onder de core ontwikkelaars. Indien nodig heeft WordPress ook gastcommitters, individuen die commit-toegang krijgen, soms voor een specifiek onderdeel, op tijdelijke of proefbasis.

De core en bijdragende ontwikkelaars begeleiden in eerste instantie de ontwikkeling van WordPress. Met elke versie, dragen honderden ontwikkelaars code bij aan WordPress. Deze core bijdragers zijn vrijwilligers die op de één of andere manier bijdragen aan de core codebase.

De WordPress Release Cyclus

Elke WordPress-releasecyclus wordt geleid door een of meer van de belangrijkste WordPress-ontwikkelaars. Een releasecyclus duurt meestal ongeveer 4 maanden vanaf de eerste scopingvergadering tot de lancering van de versie.

Een release cycle volgt de volgende stappen2:

  • Fase 1: het plannen en vastleggen van teamleider. Dit wordt gedaan in de #core chat room op Slack. De release lead bespreekt features voor de volgende release van WordPress met WordPress contributors. De release lead bepaalt dan teamleiders voor elke van deze features.
  • Fase 2: het ontwikkelen begint. Teamleiders verzamelen teams en werken aan hun toegekende features. Er worden regelmatig chats ingeroosterd om er voor te zorgen dat het ontwikkelen voortgang blijft houden.
  • Fase 3: Beta. Beta's worden vrijgegeven en beta testers worden verzocht om bugs te rapporteren. Er worden geen commits meer gedaan voor nieuwe verbeteringen of feature request vanaf deze fase. Plugin en thema bouwers van derde partij worden aangeraden om hun code te testen tegenover de aankomende veranderingen.
  • Fase 4: Release Candidate. Er is een string freeze voor vertaalstrings vanaf dit moment. Het werk heeft vanaf dit moment enkel een focus op regressies en blockers.
  • Fase 5: Lancering. De nieuwe WordPress versie wordt vrijgegeven en beschikbaar gemaakt in het WordPress Dashboard voor updates.

Versie nummering Security Releases

Een belangrijke WordPress-versie wordt gedicteerd door de eerste twee reeksen. 3.5 is bijvoorbeeld een belangrijke release, evenals 3.6, 3.7 of 4.0. Er is geen “WordPress 3” of “WordPress 4” en elke major release wordt aangeduid met de nummering, bijvoorbeeld “WordPress 3.9.”

Grote releases kunnen nieuwe gebruikersfuncties en ontwikkelaar-API's toevoegen. Hoewel meestal in de softwarewereld, is een “major” versie betekent dat je compatibiliteit met eerdere versies kunt verbreken, WordPress streeft ernaar nooit compatibiliteit met eerdere versies te beëindigen. Backwards compatibiliteit is een van de belangrijkste filosofieën van het project, met het doel om updates veel gemakkelijker te maken voor zowel gebruikers als ontwikkelaars.

Een kleine WordPress-versie wordt gedicteerd door de derde reeks. Versie 3.5.1 is een kleine release, net als 3.4.23. Een kleine release is gereserveerd voor het oplossen van beveiligingskwetsbaarheden en alleen voor het aanpakken van kritieke fouten. Omdat nieuwe versies van WordPress zo vaak worden uitgebracht — het doel is om de 4-5 maanden voor een belangrijke release, en kleine releases vinden plaats wanneer dat nodig is — is er enkel een behoefte aan major en minor releases.

Versie Backwards Compatibility

Het WordPress-project is sterk gericht op backwards compatibiliteit. Deze toewijding betekent dat thema's, plugins en custom code blijven functioneren wanneer de core software van WordPress wordt bijgewerkt, waardoor site- eigenaren worden aangemoedigd hun WordPress-versie bij te werken naar de nieuwste veilige versie.

WordPress en beveiliging

Het WordPress Security Team

Het WordPress Security Team bestaat ongeveer uit 50 experts waaronder hoofdontwikkelaars en beveiligingsonderzoekers — ongeveer de helft zijn medewerkers van Automattic (makers van WordPress.com, het eerste en grootste WordPress hostingplatform op het web) en een aantal werken op het gebied van webbeveiliging. Het team overlegt met bekende en vertrouwde beveiligingsonderzoekers en hostingbedrijven3.

Het WordPress Security Team werkt vaak samen met andere beveiligingsteams om problemen in gemeenschappelijke afhankelijkheden aan te pakken, zoals het oplossen van de kwetsbaarheid in de PHP XML-parser, gebruikt door de XML-RPC API die wordt geleverd met WordPress, in WordPress 3.9.24. Deze kwetsbaarheidsresolutie was het resultaat van een gezamenlijke inspanning van zowel WordPress- als Drupal-beveiligingsteams.

WordPress veiligheidsrisico's, processen en geschiedenis

Het WordPress Security Team gelooft in Responsible Disclosure door het beveiligingsteam onmiddellijk op de hoogte te stellen van mogelijke kwetsbaarheden. Potentiële kwetsbaarheden in de beveiliging kunnen via het netwerk worden gemeld aan het Beveiligingsteam WordPress HackerOne5. Het Beveiligingsteam communiceert onderling via een privé Slack-kanaal en werkt aan een ommuurde, persoonlijke Trac voor het traceren, testen en oplossen van bugs en beveiligingsproblemen.

Elk beveiligingsrapport wordt bij ontvangst bevestigd en het team werkt aan het verifiëren van de kwetsbaarheid en het vaststellen van de ernst ervan. Als dit wordt bevestigd, plant het beveiligingsteam vervolgens een patch om het probleem op te lossen dat kan worden gepleegd voor een komende release van de WordPress-software of kan worden gepusht als een onmiddellijke beveiligingsrelease, afhankelijk van de ernst van het probleem.

Voor een onmiddellijke beveiligingsrelease wordt door het beveiligingsteam een ​​advies gepubliceerd op de WordPress.org News-site6 als aankondiging van de release en detaillering van de wijzigingen. Krediet voor de verantwoordelijke bekendmaker van een kwetsbaarheid wordt in het advies gegeven om verdere verantwoordelijke rapportage in de toekomst te stimuleren en te versterken.

Beheerders van de WordPress-software zien een melding op het dashboard van hun site om te upgraden wanneer een nieuwe release beschikbaar is en na de handmatige upgrade worden gebruikers omgeleid naar het About WordPress scherm waarin de wijzigingen worden beschreven. Als beheerders automatische achtergrondupdates hebben ingeschakeld, ontvangen ze een e-mail nadat een upgrade is voltooid.

Automatische Updates op de achtergrond voor Security Releases

Vanaf versie 3.7 introduceerde WordPress geautomatiseerde achtergrondupdates voor alle kleinere releases7, zoals 3.7.1 en 3.7.2. Het WordPress Security Team kan geautomatiseerde beveiligingsverbeteringen voor WordPress identificeren, repareren en uitdragen zonder dat de eigenaar van de site iets aan zijn of haar kant moet doen en de beveiligingsupdate zal automatisch worden geïnstalleerd.

Wanneer een beveiligingsupdate wordt gepubliceerd voor de huidige stabiele versie van WordPress, zal het core team ook beveiligingsupdates publiceren voor alle releases die achtergrondupdates kunnen verwerken (sinds WordPress 3.7). Daarmee ontvangen deze oudere, maar nog steeds recente versies van WordPress, nog steeds beveiligingsverbeteringen.

Individuele site-eigenaren kunnen ervoor kiezen om automatische achtergrondupdates te deactiveren middels een eenvoudige wijziging in hun configuratiebestand, maar het in stand houden van deze functionaliteit wordt sterk aanbevolen door het core team, evenals het draaien van de laatste stabiele release van WordPress.

2013 OWASP Top 10

Het Open Web Application Security Project (OWASP) is een online community die zich richt op beveiliging van webtoepassingen. De OWASP Top 10-lijst8 richt zich op het identificeren van de meest serieuze beveiligingsrisico's van applicaties voor een breed scala aan organisaties. De Top 10-items worden geselecteerd en geprioriteerd in combinatie met consensusschattingen van de exploiteerbaarheid, detecteerbaarheid en impactschattingen.

In de volgende secties worden de API's, bronnen en beleidsregels besproken die WordPress gebruikt om de kernsoftware en plug-ins en thema's van derden te versterken tegen deze potentiële risico's.

A1 - Injection

Er zijn een reeks functies en API's beschikbaar in WordPress om ontwikkelaars te helpen te voorkomen dat niet-geautoriseerde code kan worden geïnjecteerd en om te helpen data te valideren en op te schonen. Beste werkwijzen en documentatie zijn beschikbaar9 over hoe deze API's te gebruiken om input en output data te valideren en opschonen in HTML, URL's, HTTP-headers en bij interactie met de database en het bestandssysteem. Beheerders kunnen ook verder beheren welke bestandstypes kunnen worden geüpload via filters.

A2 - Broken Authentication and Session Management

WordPress core-software beheert gebruikersaccounts en verificatie alsook details zoals het gebruikers-ID, de naam en het wachtwoord worden op de server beheerd, evenals de authenticatiecookies. Wachtwoorden worden beschermd in de database met behulp van standaard salting en stretching technieken. Bestaande sessies worden bij het uitloggen vernietigd vanaf WordPress 4.0.

A3 - Cross Site Scripting (XSS)

WordPress biedt een reeks functies die ervoor kunnen zorgen dat door gebruikers geleverde data veilig is10. Vertrouwde gebruikers, dat wil zeggen de beheerders en redacteuren op een WordPress-installatie en superadministrators in een WordPress Multisite, kunnen ongefilterde HTML of JavaScript publiceren in een bericht of pagina . Onvertrouwde gebruikers en door gebruikers ingediende content worden standaard gefilterd om gevaarlijke entiteiten te verwijderen, met behulp van de KSES-library via dewp_kses functie.

Als een voorbeeld merkte het core team van WordPress vóór de release van WordPress 2.3 op dat de functie the_search_query() verkeerd werd gebruikt door de meeste themabouwers door de output van die functie niet te escapen in de HTML. In een zeer zeldzaam geval van enigszins backwards compatability te verbreken werd de uitvoer van de functie in WordPress 2.3 gewijzigd zodat de output automatisch werd geëscaped.

A4 - Insecure Direct Object Reference

WordPress biedt vaak directe objectreferentie , zoals unieke numerieke ID's van gebruikersaccounts of inhoud die beschikbaar is in de URL- of formuliervelden. Hoewel deze ID's directe systeeminformatie bevatten, is WordPress haar rijke machtiging- en toegangscontrolesystemen voorkomen ongeautoriseerde verzoeken.

A5 - Security Misconfiguration

Het merendeel van de WordPress beveiligingsconfiguratiewerkzaamheden zijn beperkt tot één bevoegde beheerder. Standaardinstellingen voor WordPress worden continu geëvalueerd door het WordPress Core team en dit team biedt documentatie en aanbevolen procedures aan om de beveiliging in serverconfiguraties voor het draaien van een WordPress-site aan te scherpen11.

A6 - Gevoelige Data Exposure

WordPress wachtwoorden voor gebruikersaccounts worden salted en gehashed op basis van het Portable PHP Password Hashing Framework12. WordPress haar toestemmingssysteem wordt gebruikt om toegang tot privé-informatie te regelen zoals geregistreerde gebruikers PII, e-mailadressen van reageerders, privé gepubliceerde content, etc. In WordPress 3.7 werd een wachtwoordsterktemeter toegevoegd tot de core software waarmee aanvullende informatie aan gebruikers word verstrekt tijdens het instellen van wachtwoorden en hints over het vergroten van de sterkte hiervan. WordPress heeft ook een optionele configuratie-instelling voor het verplichten van HTTPS.

A7 - Ontbrekende Function Level Access Control

WordPress controleert de juiste autorisatie en toestemmingen voor elk functieniveau toegang verzoeken voorafgaand aan de actie wordt uitgevoerd. 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 onbevoegde gebruikers te voorkomen.

A8 - Cross Site Request Forgery (CSRF)

WordPress maakt gebruik van cryptografische tokens, nonces genaamd13, om de geldigheid van verzoeken van geautoriseerde gebruikers te beschermen tegen mogelijke CSRF bedreigingen. WordPress biedt een API voor het genereren en verifiëren van unieke en tijdelijke tokens. Het token is beperkt tot een specifieke gebruiker, een specifieke actie, een specifiek object en een specifieke tijdsperiode, die toegevoegd kan worden aan formulieren en URL's indien nodig. Daarnaast worden alle nonces ongeldig gemaakt bij het afmelden.

A9 -Het gebruik van Components met Known Vulnerabilities

Het coreteam van WordPress volgt nauwgezet de weinige opgenomen libaries en frameworks die WordPress integreert voor core functionaliteit. In het verleden heeft het kernteam bijdragen aan verschillende onderdelen van derden om deze beter te beveiligen, zoals de update naar een cross-site vulnerability in TinyMCE in WordPress 3.5.214.

Indien nodig kan het coreteam beslissen kritieke externe componenten te forken of te vervangen. Bijvoorbeeld wanneer de SWFUpload-library officieel werd vervangen door de Plupload-library in 3.5.2 en een veilige vork van SWFUpload beschikbaar werd gesteld door het beveiligingsteam <15voor die plugins die SWFUpload op korte termijn bleven gebruiken.

A10 - Ongevalideerde Redirects en Forwards

Het interne toegangs- en authenticatiesysteem van WordPress beschermt tegen pogingen om gebruikers naar ongewenste bestemingen door te sturen. Deze functionaliteit is ook beschikbaar gemaakt voor plugin ontwikkelaars via de wp_safe_redirect()16 API.

Verdere veiligheidsrisico's en -zorgen

XXE (XML eXternal Entity) processing attacks

Bij het verwerken van XML schakelt WordPress het laden van aangepaste XML-entiteiten uit om aanvallen van zowel de externe entiteit als de entiteituitbreiding te voorkomen. Naast PHP haar kernfunctionaliteit, biedt WordPress geen extra beveiligde XML-verwerkings-API voor plugin- auteurs.

SSRF (Server Side Request Forgery) aanvallen

HTTP aanvragen door WordPress worden gefilterd om toegang tot loopback en privé IP adressen te voorkomen. Daarnaast is toegang alleen toegestaan voor bepaalde HTTP poorten.

WordPress plugin en thema veiligheid

Het standaard thema

WordPress vereist dat een thema in inhoud zichtbaar in de frontend kan redeneren. Het standaard thema dat met WordPress komt (momenteel "Twenty Twenty") is intensief beoordeeld en getest om veiligheidsredenen, zowel door het team van thema ontwikkelaars en het core ontwikkelaars team.

Het standaard thema kan dienen als een startpunt voor custom thema ontwikkeling, en site ontwikkelaars kunnen subthema's bouwen die aanpassingen bevatten maar terugvallen op het standaard thema voor de meeste functionaliteit en veiligheid. Het standaard thema kan gemakkelijk verwijderd worden door een beheerder, als het niet nodig is.

WordPress.org Thema en Plugin repositories

Er zijn ongeveer 50.000+ plugins en 5.000 thema's beschikbaar op de WordPress.org site. Deze thema's en plugins worden ingezonden voor opname en worden handmatig beoordeeld door vrijwilligers voordat ze beschikbaar worden gemaakt op de repository.

Plugins en thema's zijn niet gevrijwaard van van veiligheidslekken wanneer ze in de repository staan. Er zijn richtlijnen voor plugin auteurs om te raadplegen voor inzending naar de repository17, en uitgebreide documentatie over WordPress thema ontwikkeling18 is beschikbaar op de WordPress.org site.

Elke plugin en thema kan continue door de plugin- of thema eigenaar verder ontwikkeld worden. Elke fix of ontwikkelde feature kan worden geüpload naar de repository en beschikbaar worden gemaakt voor gebruikers met die plugin of thema en een omschrijving van de verandering. Site beheerders worden op de hoogte gesteld van plugins die geüpdate moeten worden via hun admin panel.

Wanneer het WordPress veiligheidsteam een veiligheidslek in een plugin ontdekt, nemen ze contact op met de plugin auteur om samen te werken aan de oplossing en het uitbrengen van een veilige versie van de plugin. Als de plugin auteur niet reageert, of het een ernstig veiligheidslek betreft. wordt de plugin/thema uit de publieke map gehaald en, in sommige gevallen, direct gerepareerd en geüpload door het veiligheidsteam.

Het Thema Review Team

Het Theme Review Team is a groep van vrijwilligers, geleid door gerenommeerde leden van de WordPress community, die nieuwe thema's die ingediend zijn bij de officiële WordPress Thema directory reviewen en goedkeuren. Het Theme Review Team onderhoudt ook de officiële Theme Review Guidelines19, de Theme Unit Test Datas20, de Theme Check Plugins21 en onderhoud de WordPress Theme developer community met betrekking tot best practices voor het ontwikkelen van thema's. Ledenbeheer is gemodereerd door core committers van het WordPress ontwikkel team.

De rol van het webhostingbedrijf m.b.t. WordPress Security

WordPress kan geïnstalleerd worden op een grote verscheidenheid van platformen. Ondanks dat de WordPress core software op vele manieren een veilige web applicatie verzorgd, is de configuratie van de server software bij een web host minstens zo belangrijk als het gaat om WordPress applicaties veilig te houden.

Een opmerking over WordPress.com en WordPress security

WordPress.com is de grootste WordPress installatie ter wereld en is van Automattic, Inc., opgericht door Matt Mullenweg, de mede-oprichter van het WordPress project. WordPress.com draait op de core WordPress software, en heeft haar eigen veiligheidsprocessen, risico's en oplossingen22. Dit document verwijst naar veiligheid met betrekking tot de zelf gehoste en downloadbare open source WordPress software beschikbaar vanaf WordPress.org welke op elke server in de wereld geïnstalleerd kan worden.

Appendix

Core WordPress API's

De WordPress Core Application Programming Interface (API) bestaat uit verschillende APIs23. Samen vormen ze de project interface door middel van plugins en thema's met de WordPress core functionaliteit interacteren op een veilige manier.

Elke WordPress API verzorgt best practices en biedt gestandariseerde manieren om met de WordPress core software te werken, maar de volgende WordPress API's zijn het meest belangrijk als het gaat om het implementeren van WordPress security:

Database API

De Database API24, toegevoegd in WordPress 0.71, verzorgd de correcte method om data zoals named values uit de database laag te halen.

Filesystem API

De Filesystem API25, toegevoegd in WordPress 2.626, was oorspronkelijk geschreven voor de automatische updates van WordPress zelf. De Filesystem API regelt de functionaliteit die er nodig is om veilig bestanden te lezen en weg te schrijven in het lokale bestandsysteem voor een grote verscheidenheid van hosting configuraties.

Het doet dit door middel van het WP_Filesystem_Base class, en verschillende subclasses die verschillende manieren implementeren om te verbinden met het lokale bestandssysteem, rekening houdend met je server. Elk thema of plugins die lokaal bestanden wil wegschrijven moet dit doen met de WP_Filesystem verzameling van classes.

HTTP API

De HTTP API27, toegevoegd in WordPress 2.728 en uitgebreid in WordPress 2.8, standariseert de HTTP requests voor WordPress. De API behandeld cookies, gzip encoding en decoding, chunk decoding (indien HTTP 1.1), en overige andere HTTP protocol implementaties. De API standariseert requests, test elke method voordat het verstuurd en, gebaseerd op je serverconfiguratie, gebruikte de correcte method om het request te doen.

Rechten en huidige gebruiker API

De toegangsrechten en current-user-API29 bestaat uit een verzameling van functies die de rechten van een gebruiker verifiëren wanneer er deze een taak wil uitvoeren. Op worden acties die buiten de toegestane rechten vallen tegengehouden.

Whitepaper inhoud licentie

De tekst in dit document (exclusief het WordPress logo of handelsmerk valt onder het CC0 1.0 Universal (CC0 1.0) Public Domain Dedication handelsmerk. Je kunt het kopiëren, bewerken en verspreiden, zelfs voor commerciële doeleinden, zonder dat je hiervoor toestemming nodig hebt.

Een speciaal dankwoord voor het whitepaper over veiligheidvan Drupal, voor de geboden inspiratie.

Extra leesmateriaal

Geschreven door Sara Rosso

Bijdragen van Barry Abrahamson, Michael Adams, Jon Cave, Helen Hou-Sandí, Dion Hulse, Mo Jangda en Paul Maiorana

Versie 1.0 Maart 2015

Voetnoten