Sécurité

Learn more about WordPress core software security in this free white paper. You can also download it in PDF format.

Vue d’ensemble

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.

Executive Summary

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 35% 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.

Site developers and administrators should pay particular attention to the correct use of core APIs and underlying server configuration which have been the source of common vulnerabilities, as well as ensuring all users employ strong passwords to access WordPress.

Une vue d’ensemble de 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 35% 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. La liberté d’exécuter le programme, pour n’importe quel but.
  2. La liberté d’étudier comment fonctionne le programme, et de le changer pour qu’il fasse ce que vous souhaitez.
  3. La liberté de redistribuer.
  4. La liberté de distribuer à d’autres des copies de vos versions modifiées.

L’équipe de direction du cœur WordPress

The WordPress project is a meritocracy, run by a core leadership team, and led by its co-creator and lead developer, Matt Mullenweg. The team governs all aspects of the project, including core development, WordPress.org, and community initiatives.

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.

The WordPress Release Cycle

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.

A release cycle follows the following pattern2:

  • Phase 1: Planning and securing team leads. This is done in the #core chat room on Slack. The release lead discusses features for the next release of WordPress. WordPress contributors get involved with that discussion. The release lead will identify team leads for each of the 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.
  • Phase 5: Launch. WordPress version is launched and made available in the WordPress Admin for updates.

Version Numbering and Security Releases

A major WordPress version is dictated by the first two sequences. For example, 3.5 is a major release, as is 3.6, 3.7, or 4.0. There isn’t a “WordPress 3” or “WordPress 4” and each major release is referred to by its numbering, e.g., “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.

A minor WordPress version is dictated by the third sequence. Version 3.5.1 is a minor release, as is 3.4.23. A minor release is reserved for fixing security vulnerabilities and addressing critical bugs only. Since new versions of WordPress are released so frequently — the aim is every 4-5 months for a major release, and minor releases happen as needed — there is only a need for major and minor releases.

Version 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 et la sécurité

L’équipe de sécurité de WordPress

The WordPress Security Team is made up of approximately 50 experts including lead developers and security researchers — about half are employees of Automattic (makers of WordPress.com, the earliest and largest WordPress hosting platform on the web), and a number work in the web security field. The team consults with well-known and trusted security researchers and hosting companies3.

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 Security Risks, Process, and History

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.

Automatic Background Updates for Security Releases

Starting with version 3.7, WordPress introduced automated background updates for all minor releases7, such as 3.7.1 and 3.7.2. The WordPress Security Team can identify, fix, and push out automated security enhancements for WordPress without the site owner needing to do anything on their end, and the security update will install automatically.

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.

Individual site owners can opt to remove automatic background updates through a simple change in their configuration file, but keeping the functionality is strongly recommended by the core team, as well as running the latest stable release of 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.

The following sections discuss the APIs, resources, and policies that WordPress uses to strengthen the core software and 3rd party plugins and themes against these potential risks.

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 manages user accounts and authentication and details such as the user ID, name, and password are managed on the server-side, as well as the authentication cookies. Passwords are protected in the database using standard salting and stretching techniques. Existing sessions are destroyed upon logout for versions of WordPress after 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.

As an example, the WordPress core team noticed before the release of WordPress 2.3 that the function the_search_query() was being misused by most theme authors, who were not escaping the function’s output for use in HTML. In a very rare case of slightly breaking backward compatibility, the function’s output was changed in WordPress 2.3 to be pre-escaped.

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

The majority of the WordPress security configuration operations are limited to a single authorized administrator. Default settings for WordPress are continually evaluated at the core team level, and the WordPress core team provides documentation and best practices to tighten security for server configuration for running a WordPress site11.

A6 - Sensitive 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 - Missing Function Level Access Control

WordPress checks for proper authorization and permissions for any function level access requests prior to the action being executed. Access or visualization of administrative URLs, menus, and pages without proper authentication is tightly integrated with the authentication system to prevent access from unauthorized users.

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 - Using Components with 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.

If necessary, the core team may decide to fork or replace critical external components, such as when the SWFUpload library was officially replaced by the Plupload library in 3.5.2, and a secure fork of SWFUpload was made available by the security team<15 for those plugins who continued to use SWFUpload in the short-term.

A10 - Unvalidated Redirects and Forwards

WordPress’ internal access control and authentication system will protect against attempts to direct users to unwanted destinations or automatic redirects. This functionality is also made available to plugin developers via an API, wp_safe_redirect()16.

Autres risques concernant la sécurité

Attaques sur les processus XXE (XML eXternal Entity)

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.

Attaques SSRF (Server Side Request Forgery)

Les requêtes HTTP sur WordPress sont filtrées pour éviter tout retour de données et d’adresses IP privées. De plus, l’accès n’est autorisé que sur certains ports HTTP standards.

Sécurité des extensions et thèmes WordPress

Le thème par défaut

WordPress nécessite un thème pour pouvoir rendre le contenu visible sur l’interface publique. Le thème par défaut fourni avec le noyau WordPress (actuellement « Twenty Twenty ») a été passé en revue et testé en profondeur au niveau sécurité à la fois par l’équipe des développeurs du thème et par l’équipe de développement du noyau.

Le thème par défaut peut servir comme point de départ pour le développement d’un thème personnalisé et les développeurs de site peuvent créer un thème enfant incluant une certaine personnalisation mais qui s’appuie sur le thème par défaut pour la plupart des fonctionnalités et la sécurité. Le thème par défaut peut être facilement supprimé par un administrateur s’il ne s’avère pas nécessaire.

Dépôts des thèmes et extensions WordPress.org

Il y a approximativement 50 000+ extensions et 5 000+ thèmes listés sur le site WordPress.org. Ces thèmes et extensions sont d’abord soumis en vue d’être ajoutés et sont manuellement passés en revue par des volontaires avant d’être mis à disposition sur le dépôt.

L’ajout d’extensions et de thèmes dans le répertoire ne garantit pas qu’ils soient exempts de failles de sécurité. Les auteurs d’extension doivent consulter les lignes de conduite qui leur sont fournies avant toute soumission en vue d’un ajout au dépôt17, et une vaste documentation axée sur le développement18 de thème WordPress est disponible sur le site WordPress.org.

Chaque extension ou thème est susceptible d’être amélioré par son créateur. Tous les correctifs qui en découlent ou tout développement de fonctionnalité peuvent être téléversés sur le dépôt et mis à la disposition des utilisateurs ayant installé cette extension ou ce thème, avec une description de ce changement. Les administrateurs du site sont informés des extensions qui doivent être mises à jour via le tableau de bord de leur interface d’administration.

Quand l’équipe sécurité de WordPress découvre une vulnérabilité dans une extension, elle contacte son auteur·e pour qu’ils travaillent ensemble afin de la corriger et de publier une version sécurisée. Si l’auteur de l’extension ne répond pas ou lorsque la faille de sécurité est grave, l’extension/le thème est retiré du répertoire public et, dans certains cas, corrigé et mis à jour par l’équipe de sécurité.

L’équipe de validation des thèmes (Theme Review Team)

L’équipe de validation des thèmes (Theme Review Team) est un groupe de bénévoles conduit par des membres-clés et estimés de la communauté, qui vérifient et valident les thèmes proposés pour être disponibles sur le répertoire officiel de thèmes. Cette équipe maintient les guidelines officielles de Validation des thèmes19, les données de tests unitaires20, l’extension Theme Check21 et essaye d’encourager la communauté de développeur·ses de thèmes WordPress à suivre les bonnes pratiques de développement. L’inclusion dans ce groupe est modérée par les Core committers de l’équipe de développement de WordPress.

Le rôle du fournisseur d’hébergement dans la sécurisation de WordPress

WordPress peut être installé sur une multitude de plates-formes. Bien que le logiciel du noyau de WordPress fournisse de nombreuses dispositions pour exploiter une application Web sécurisée, qui ont été couvertes dans ce document, la configuration du système d’exploitation et du serveur Web sous-jacent hébergeant le logiciel est tout aussi importante pour préserver la sécurité des applications WordPress.

Une note à propos de WordPress.com et de la sécurité de WordPress

WordPress.com, qui est la plus grosse installation de WordPress au Monde, est possédé et géré par la société Automattic, fondée par Matt Mullenweg, le co-créateur du projet WordPress. WordPress.com, qui fonctionne avec le noyau du logiciel WordPress, possède ses propres processus, risques et solutions de sécurité22. Ce document fait référence à la sécurité du logiciel open source WordPress, téléchargeable, auto-hébergé par WordPress.org et installable sur n’importe quel serveur dans le Monde.

Annexe

API du cœur WordPress

L’API (Application Programming Interface) du noyau WordPress contient plusieurs API23 individuelles. Chacune d’entre elle couvre un champ d’action bien particulier. Ensemble, elles forment l’interface qui permet aux extensions et thèmes d’altérer, étendre et interagir avec les fonctionnalités du cœur de manière sécurisée.

Avec chaque API WordPress, des bonnes pratiques standardisées sont fournies pour interagir et étendre le cœur du logiciel WordPress. Les API suivantes sont les plus importantes pour renforcer la sécurité de WordPress :

API Database

Ajoutée dans WordPress 0.71, l’API Database24 fournit la bonne méthode pour accéder aux données en tant que valeurs nominatives stockées dans la couche d’abstraction de la base de données.

API Filesystem

The Filesystem API25, added in WordPress 2.626, was originally created for WordPress’ own automatic updates feature. The Filesystem API abstracts out the functionality needed for reading and writing local files to the filesystem to be done securely, on a variety of host types.

Cela se passe par le biais de la classe WP_Filesystem_Base et de plusieurs sous-classes qui comprennent différentes façon de se connecter au système de fichiers local, suivant ce que supporte l’hébergeur. Tout thème ou extension ayant besoin d’écrire localement sur des fichiers doit utiliser la famille de classes WP_Filesystem.

HTTP API

Ajoutée dans WordPress 2.728 puis étendue dans WordPress 2.8, l’API HTTP27 standardise les requêtes HTTP de WordPress. Cette API gère les Cookies, l’encodage et décodage GZIP, le décodage de Chunk (pour HTTP 1.1), et plusieurs autres implémentations du protocole HTTP. L’API standardise les requêtes, teste chaque méthode avant envoi et, suivi votre configuration serveur, utilise la méthode appropriée pour effectuer chaque requête.

Les API Permissions & Current User

The permissions and current user API29 is a set of functions which will help verify the current user’s permissions and authority to perform any task or operation being requested, and can protect further against unauthorized users accessing or performing functions beyond their permitted capabilities.

Licence appliquable aux contenus des livres blancs

Le texte de ce document (hormis le logo WordPress ou la marque commerciale associée) est sous licence CC0 1.0 universal (CC0 1.0) Transfert dans le Domaine Public. Vous pouvez copier, modifier, distribuer et représenter l’œuvre, même à des fins commerciales, sans avoir besoin de demander l’autorisation.

A special thank you to Drupal’s security white paper, which provided some inspiration.

Lectures additionnelles

Réalisé par Sara Rosso

Contributions de Barry Abrahamson, Michael Adams, Jon Cave, Helen Hou-Sandí, Dion Hulse, Mo Jangda, Paul Maiorana

Version 1.0 mars 2015

Notes de pied de page