Beveiliging

Leer meer over WordPress core softwarebeveiliging in dit gratis whitepaper. Je kunt het ook downloaden in PDF-formaat.

Overzicht

This document is an analysis and explanation of the WordPress core software development and its related security processes, as well as an examination of the inherent security built directly into the software. Decision makers evaluating WordPress as a content management system or web application framework should use this document in their analysis and decision-making, and for developers to refer to it to familiarize themselves with the security components and best practices of the software.

The information in this document is up-to-date for the latest stable release of the software, WordPress 4.7 at time of publication, but should be considered relevant also to the most recent versions of the software as backwards compatibility is a strong focus for the WordPress development team. Specific security measures and changes will be noted as they have been added to the core software in specific releases. It is strongly encouraged to always be running the latest stable version of WordPress to ensure the most secure experience possible.

Samenvatting

WordPress is a dynamic open-source content management system which is used to power millions of websites, web applications, and blogs. It currently powers more than 42% of the top 10 million websites on the Internet. WordPress’ usability, extensibility, and mature development community make it a popular and secure choice for websites of all sizes.

Since its inception in 2003, WordPress has undergone continual hardening so its core software can address and mitigate common security threats, including the Top 10 list identified by The Open Web Application Security Project (OWASP) as common security vulnerabilities, which are discussed in this document.

The WordPress Security Team, in collaboration with the WordPress Core Leadership Team and backed by the WordPress global community, works to identify and resolve security issues in the core software available for distribution and installation at WordPress.org, as well as recommending and documenting security best practices for third-party plugin and theme authors.

Siteontwikkelaars en beheerders moeten bijzondere aandacht besteden aan het juiste gebruik van de core 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 a free and open source content management system (CMS). It is the most widely-used CMS software in the world and it powers more than 42% of the top 10 million websites1, giving it an estimated 62% market share of all sites using a CMS.

WordPress is licensed under the General Public License (GPLv2 or later) which provides four core freedoms, and can be considered as the 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 founder, Matt Mullenweg. Het team beheert alle aspecten van het project, inclusief core-ontwikkeling, WordPress.org en community initiatieven.

The Core Leadership Team consists of Matt Mullenweg, five lead developers, and more than a dozen core developers with permanent commit access. These developers have final authority on technical decisions, and lead architecture discussions and implementation efforts.

WordPress has a number of contributing developers. Some of these are former or current committers, and some are likely future committers. These contributing developers are trusted and veteran contributors to WordPress who have earned a great deal of respect among their peers. As needed, WordPress also has guest committers, individuals who are granted commit access, sometimes for a specific component, on a temporary or trial basis.

The core and contributing developers primarily guide WordPress development. Every version, hundreds of developers contribute code to WordPress. These core contributors are volunteers who contribute to the core codebase in some way.

De WordPress Release Cyclus

Each WordPress release cycle is led by one or more of the core WordPress developers. A release cycle usually lasts around 4 months from the initial scoping meeting to launch of the version.

Een release cycle volgt de volgende stappen2:

  • Fase 1: het plannen en vastleggen van team leiders. 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.
  • Phase 2: Development work begins. Team leads assemble teams and work on their assigned features. Regular chats are scheduled to ensure the development keeps moving forward.
  • Phase 3: Beta. Betas are released, and beta-testers are asked to start reporting bugs. No more commits for new enhancements or feature requests are carried out from this phase on. Third-party plugin and theme authors are encouraged to test their code against the upcoming changes.
  • Phase 4: Release Candidate. There is a string freeze for translatable strings from this point on. Work is targeted on regressions and blockers only.
  • 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.”

Major releases may add new user features and developer APIs. Though typically in the software world, a “major” version means you can break backwards compatibility, WordPress strives to never break backwards compatibility. Backwards compatibility is one of the project’s most important philosophies, with the aim of making updates much easier on users and developers alike.

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

The WordPress project has a strong commitment to backwards compatibility. This commitment means that themes, plugins, and custom code continues to function when WordPress core software is updated, encouraging site owners to keep their WordPress version updated to the latest secure release.

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.

The WordPress Security Team often collaborates with other security teams to address issues in common dependencies, such as resolving the vulnerability in the PHP XML parser, used by the XML-RPC API that ships with WordPress, in WordPress 3.9.24. This vulnerability resolution was a result of a joint effort by both WordPress and Drupal security teams.

WordPress veiligheidsrisico's, processen en geschiedenis

The WordPress Security Team believes in Responsible Disclosure by alerting the security team immediately of any potential vulnerabilities. Potential security vulnerabilities can be signaled to the Security Team via the WordPress HackerOne5. The Security Team communicates amongst itself via a private Slack channel, and works on a walled-off, private Trac for tracking, testing, and fixing bugs and security problems.

Each security report is acknowledged upon receipt, and the team works to verify the vulnerability and determine its severity. If confirmed, the security team then plans for a patch to fix the problem which can be committed to an upcoming release of the WordPress software or it can be pushed as an immediate security release, depending on the severity of the issue.

For an immediate security release, an advisory is published by the Security Team to the WordPress.org News site6 announcing the release and detailing the changes. Credit for the responsible disclosure of a vulnerability is given in the advisory to encourage and reinforce continued responsible reporting in the future.

Administrators of the WordPress software see a notification on their site dashboard to upgrade when a new release is available, and following the manual upgrade users are redirected to the About WordPress screen which details the changes. If administrators have automatic background updates enabled, they will receive an email after an upgrade has been completed.

Automatische Updates op de achtergrond voor Security Releases

Vanaf versie 3.7 introduceerde WordPress geautomatiseerde achtergrondupdates voor alle kleine releases7, zoals 3.7.1 en 3.7.2. Het WordPress Security Team kan geautomatiseerde beveiligingsverbeteringen voor WordPress identificeren, repareren en pushen zonder dat de eigenaar van de website iets hoeft te doen aan zijn kant, de beveiligingsupdate zal automatisch worden geïnstalleerd.

When a security update is pushed for the current stable release of WordPress, the core team will also push security updates for all the releases that are capable of background updates (since WordPress 3.7), so these older but still recent versions of WordPress will receive security enhancements.

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

The Open Web Application Security Project (OWASP) is an online community dedicated to web application security. The OWASP Top 10 list8 focuses on identifying the most serious application security risks for a broad array of organizations. The Top 10 items are selected and prioritized in combination with consensus estimates of exploitability, detectability, and impact estimates.

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

A1 - Injection

There is a set of functions and APIs available in WordPress to assist developers in making sure unauthorized code cannot be injected, and help them validate and sanitize data. Best practices and documentation are available9 on how to use these APIs to protect, validate, or sanitize input and output data in HTML, URLs, HTTP headers, and when interacting with the database and filesystem. Administrators can also further restrict the types of file which can be uploaded 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 opgeslagen, 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 provides a range of functions which can help ensure that user-supplied data is safe10. Trusted users, that is administrators and editors on a single WordPress installation, and network administrators only in WordPress Multisite, can post unfiltered HTML or JavaScript as they need to, such as inside a post or page. Untrusted users and user-submitted content is filtered by default to remove dangerous entities, using the KSES library through the wp_kses function.

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 often provides direct object reference, such as unique numeric identifiers of user accounts or content available in the URL or form fields. While these identifiers disclose direct system information, WordPress’ rich permissions and access control system prevent unauthorized requests.

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 website aan te scherpen11.

A6 - Gevoelige Data Exposure

WordPress user account passwords are salted and hashed based on the Portable PHP Password Hashing Framework12. WordPress’ permission system is used to control access to private information such an registered users’ PII, commenters’ email addresses, privately published content, etc. In WordPress 3.7, a password strength meter was included in the core software providing additional information to users setting their passwords and hints on increasing strength. WordPress also has an optional configuration setting for requiring HTTPS.

A7 - Ontbrekende Function Level Access Control

WordPress controleert eerst de juiste autorisatie en toestemmingen voor toegangverzoeken op alle functieniveaus vooraleer 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 uses cryptographic tokens, called nonces13, to validate intent of action requests from authorized users to protect against potential CSRF threats. WordPress provides an API for the generation of these tokens to create and verify unique and temporary tokens, and the token is limited to a specific user, a specific action, a specific object, and a specific time period, which can be added to forms and URLs as needed. Additionally, all nonces are invalidated upon logout.

A9 -Het gebruik van Components met Known Vulnerabilities

The WordPress core team closely monitors the few included libraries and frameworks WordPress integrates with for core functionality. In the past the core team has made contributions to several third-party components to make them more secure, such as the update to fix a 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

When processing XML, WordPress disables the loading of custom XML entities to prevent both External Entity and Entity Expansion attacks. Beyond PHP’s core functionality, WordPress does not provide additional secure XML processing API for plugin authors.

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-One") 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 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. Website 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