8 |
9 | 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.
12 | 13 |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.
14 |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 43% 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.
16 | 17 |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.
18 | 19 |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.
20 | 21 |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.
22 |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 43% of the top 10 million websites1, giving it an estimated 63% market share of all sites using a CMS.
24 | 25 |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":
26 |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.
34 | 35 |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.
36 | 37 |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.
38 | 39 |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.
40 |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.
42 | 43 |A release cycle follows the following pattern2:
44 |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."
53 | 54 |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.
55 | 56 |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.
57 | 58 |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.
60 |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.
63 | 64 |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.
65 |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.
67 | 68 |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.
69 | 70 |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.
71 | 72 |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.
73 |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.
75 | 76 |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.
77 | 78 |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.
79 |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.
81 | 82 |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.
83 |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.
85 |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.
87 |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.
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.
93 |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.
95 |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.
97 |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.
99 |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.
101 |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.
103 | 104 |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 team15 for those plugins who continued to use SWFUpload in the short-term.
105 |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.
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.
110 |HTTP requests issued by WordPress are filtered to prevent access to loopback and private IP addresses. Additionally, access is only allowed to certain standard HTTP ports.
112 |WordPress requires a theme to be enabled to render content visible on the frontend. The default theme which ships with core WordPress (currently "Twenty Fifteen") has been vigorously reviewed and tested for security reasons by both the team of theme developers plus the core development team.
115 | 116 |The default theme can serve as a starting point for custom theme development, and site developers can create a child theme which includes some customization but falls back on the default theme for most functionality and security. The default theme can be easily removed by an administrator if not needed.
117 | 118 |There are approximately 50,000+ plugins and 4,500+ themes listed on the WordPress.org site. These themes and plugins are submitted for inclusion and are manually reviewed by volunteers before making them available on the repository.
121 | 122 |Inclusion of plugins and themes in the repository is not a guarantee that they are free from security vulnerabilities. Guidelines are provided for plugin authors to consult prior to submission for inclusion in the repository17, and extensive documentation about how to do WordPress theme development18 is provided on the WordPress.org site.
123 | 124 |Each plugin and theme has the ability to be continually developed by the plugin or theme owner, and any subsequent fixes or feature development can be uploaded to the repository and made available to users with that plugin or theme installed with a description of that change. Site administrators are notified of plugins which need to be updated via their administration dashboard.
125 | 126 |When a plugin vulnerability is discovered by the WordPress Security Team, they contact the plugin author and work together to fix and release a secure version of the plugin. If there is a lack of response from the plugin author or if the vulnerability is severe, the plugin/theme is pulled from the public directory, and in some cases, fixed and updated directly by the Security Team.
127 |The Theme Review Team is a group of volunteers, led by key and established members of the WordPress community, who review and approve themes submitted to be included in the official WordPress Theme directory. The Theme Review Team maintains the official Theme Review Guidelines19, the Theme Unit Test Data20, and the Theme Check Plugin21, and attempts to engage and educate the WordPress Theme developer community regarding development best practices. Inclusion in the group is moderated by core committers of the WordPress development team.
129 |WordPress can be installed on a multitude of platforms. Though WordPress core software provides many provisions for operating a secure web application, which were covered in this document, the configuration of the operating system and the underlying web server hosting the software is equally important to keep the WordPress applications secure.
131 |WordPress.com is the largest WordPress installation in the world, and is owned and managed by Automattic, Inc., which was founded by Matt Mullenweg, the WordPress project co-creator. WordPress.com runs on the core WordPress software, and has its own security processes, risks, and solutions22. This document refers to security regarding the self-hosted, downloadable open source WordPress software available from WordPress.org and installable on any server in the world.
133 |The WordPress Core Application Programming Interface (API) is comprised of several individual APIs23, each one covering the functions involved in, and use of, a given set of functionality. Together, these form the project interface which allows plugins and themes to interact with, alter, and extend WordPress core functionality safely and securely.
136 | 137 |While each WordPress API provides best practices and standardized ways to interact with and extend WordPress core software, the following WordPress APIs are the most pertinent to enforcing and hardening WordPress security:
138 | 139 |The Database API24, added in WordPress 0.71, provides the correct method for accessing data as named values which are stored in the database layer.
142 | 143 |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.
146 | 147 |It does this through the WP_Filesystem_Base class, and several subclasses which implement different ways of connecting to the local filesystem, depending on individual host support. Any theme or plugin that needs to write files locally should do so using the WP_Filesystem family of classes.
The HTTP API27, added in WordPress 2.728 and extended further in WordPress 2.8, standardizes the HTTP requests for WordPress. The API handles cookies, gzip encoding and decoding, chunk decoding (if HTTP 1.1), and various other HTTP protocol implementations. The API standardizes requests, tests each method prior to sending, and, based on your server configuration, uses the appropriate method to make the request.
152 | 153 |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.
156 |The text in this document (not including the WordPress logo or trademark) is licensed under CC0 1.0 Universal (CC0 1.0) Public Domain Dedication. You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission.
158 | 159 |A special thank you to Drupal's security white paper, which provided some inspiration.
160 |Authored by Sara Rosso
170 | 171 |Contributions from Barry Abrahamson, Michael Adams, Jon Cave, Helen Hou-Sandí, Dion Hulse, Mo Jangda, Paul Maiorana
172 | 173 |Version 1.0 March 2015
174 | 175 |
8 |
9 | Aquest document és una anàlisi i explicació del desenvolupament del nucli del WordPress i els processos de seguretat relacionats, així com un examen de la seguretat inherent muntada al programari. Els qui prenen decisions, que avaluen el WordPress com un sistema de gestió de continguts o un entorn de treball d'aplicacions web, haurien d'utilitzar aquest document en l'anàlisi i presa de decisions, i els desenvolupadors haurien de tenir-lo com a referència per familiaritzar-se amb els components de seguretat i millors pràctiques del programari.
12 | 13 |The information in this document is up-to-date for the latest stable release of the software, WordPress 4.1 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.
14 |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 23% 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.
16 | 17 |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.
18 | 19 |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.
20 | 21 |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.
22 |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 23% of the top 10 million websites1, giving it an estimated 60% market share of all sites using a CMS.
24 | 25 |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":
26 |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.
34 | 35 |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.
36 | 37 |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.
38 | 39 |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.
40 |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.
42 | 43 |A release cycle follows the following pattern2:
44 |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."
53 | 54 |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.
55 | 56 |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.
57 | 58 |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.
60 |The WordPress Security Team is made up of approximately 25 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.
63 | 64 |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.
65 |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 directly via the email address: security@wordpress.org5. The Security Team communicates amongst itself via a private email list, and works on a walled-off, private Trac for tracking, testing, and fixing bugs and security problems.
67 | 68 |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.
69 | 70 |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.
71 | 72 |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.
73 |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.
75 | 76 |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.
77 | 78 |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.
79 |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.
81 | 82 |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.
83 |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.
85 |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.
87 |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 site 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.
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.
93 |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.
95 |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.
97 |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.
99 |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.
101 |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.
103 | 104 |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 in 3.5.2, and a secure fork of SWFUpload was made available by the security team15 for those plugins who continued to use SWFUpload in the short-term.
105 |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.
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.
110 |HTTP requests issued by WordPress are filtered to prevent access to loopback and private IP addresses. Additionally, access is only allowed to certain standard HTTP ports.
112 |WordPress requires a theme to be enabled to render content visible on the frontend. The default theme which ships with core WordPress (currently "Twenty Fifteen") has been vigorously reviewed and tested for security reasons by both the team of theme developers plus the core development team.
115 | 116 |The default theme can serve as a starting point for custom theme development, and site developers can create a child theme which includes some customization but falls back on the default theme for most functionality and security. The default theme can be easily removed by an administrator if not needed.
117 | 118 |There are approximately 30,000+ plugins and 2,000+ themes listed on the WordPress.org site. These themes and plugins are submitted for inclusion and are manually reviewed by volunteers before making them available on the repository.
121 | 122 |Inclusion of plugins and themes in the repository is not a guarantee that they are free from security vulnerabilities. Guidelines are provided for plugin authors to consult prior to submission for inclusion in the repository17, and extensive documentation about how to do WordPress theme development18 is provided on the WordPress.org site.
123 | 124 |Each plugin and theme has the ability to be continually developed by the plugin or theme owner, and any subsequent fixes or feature development can be uploaded to the repository and made available to users with that plugin or theme installed with a description of that change. Site administrators are notified of plugins which need to be updated via their administration dashboard.
125 | 126 |When a plugin vulnerability is discovered by the WordPress Security Team, they contact the plugin author and work together to fix and release a secure version of the plugin. If there is a lack of response from the plugin author or if the vulnerability is severe, the plugin/theme is pulled from the public directory, and in some cases, fixed and updated directly by the Security Team.
127 |The Theme Review Team is a group of volunteers, led by key and established members of the WordPress community, who review and approve themes submitted to be included in the official WordPress Theme directory. The Theme Review Team maintains the official Theme Review Guidelines19, the Theme Unit Test Data20, and the Theme Check Plugin21, and attempts to engage and educate the WordPress Theme developer community regarding development best practices. Inclusion in the group is moderated by core committers of the WordPress development team.
129 |WordPress can be installed on a multitude of platforms. Though WordPress core software provides many provisions for operating a secure web application, which were covered in this document, the configuration of the operating system and the underlying web server hosting the software is equally important to keep the WordPress applications secure.
131 |WordPress.com is the largest WordPress installation in the world, and is owned and managed by Automattic, Inc., which was founded by Matt Mullenweg, the WordPress project co-creator. WordPress.com runs on the core WordPress software, and has its own security processes, risks, and solutions22. This document refers to security regarding the self-hosted, downloadable open source WordPress software available from WordPress.org and installable on any server in the world.
133 |The WordPress Core Application Programming Interface (API) is comprised of several individual APIs23, each one covering the functions involved in, and use of, a given set of functionality. Together, these form the project interface which allows plugins and themes to interact with, alter, and extend WordPress core functionality safely and securely.
136 | 137 |While each WordPress API provides best practices and standardized ways to interact with and extend WordPress core software, the following WordPress APIs are the most pertinent to enforcing and hardening WordPress security:
138 | 139 |The Database API24, added in WordPress 0.71, provides the correct method for accessing data as named values which are stored in the database layer.
142 | 143 |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.
146 | 147 |It does this through the WP_Filesystem_Base class, and several subclasses which implement different ways of connecting to the local filesystem, depending on individual host support. Any theme or plugin that needs to write files locally should do so using the WP_Filesystem family of classes.
The HTTP API27, added in WordPress 2.728 and extended further in WordPress 2.8, standardizes the HTTP requests for WordPress. The API handles cookies, gzip encoding and decoding, chunk decoding (if HTTP 1.1), and various other HTTP protocol implementations. The API standardizes requests, tests each method prior to sending, and, based on your server configuration, uses the appropriate method to make the request.
152 | 153 |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.
156 |The text in this document (not including the WordPress logo or trademark) is licensed under CC0 1.0 Universal (CC0 1.0) Public Domain Dedication. You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission.
158 | 159 |A special thank you to Drupal's security white paper, which provided some inspiration.
160 |Authored by Sara Rosso
170 | 171 |Contributions from Barry Abrahamson, Michael Adams, Jon Cave, Helen Hou-Sandí , Dion Hulse, Mo Jangda, Paul Maiorana
172 | 173 |Version 1.0 March 2015
174 | 175 |
8 |
9 | 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.
12 | 13 |The information in this document is up-to-date for the latest stable release of the software, WordPress 4.1 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.
14 |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 23% 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.
16 | 17 |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.
18 | 19 |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.
20 | 21 |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.
22 |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 23% of the top 10 million websites1, giving it an estimated 60% market share of all sites using a CMS.
24 | 25 |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":
26 |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.
34 | 35 |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.
36 | 37 |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.
38 | 39 |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.
40 |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.
42 | 43 |A release cycle follows the following pattern2:
44 |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."
53 | 54 |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.
55 | 56 |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.
57 | 58 |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.
60 |The WordPress Security Team is made up of approximately 25 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.
63 | 64 |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.
65 |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 directly via the email address: security@wordpress.org5. The Security Team communicates amongst itself via a private email list, and works on a walled-off, private Trac for tracking, testing, and fixing bugs and security problems.
67 | 68 |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.
69 | 70 |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.
71 | 72 |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.
73 |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.
75 | 76 |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.
77 | 78 |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.
79 |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.
81 | 82 |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.
83 |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.
85 |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.
87 |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 site 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.
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.
93 |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.
95 |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.
97 |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.
99 |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.
101 |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.
103 | 104 |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 in 3.5.2, and a secure fork of SWFUpload was made available by the security team15 for those plugins who continued to use SWFUpload in the short-term.
105 |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.
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.
110 |HTTP requests issued by WordPress are filtered to prevent access to loopback and private IP addresses. Additionally, access is only allowed to certain standard HTTP ports.
112 |WordPress requires a theme to be enabled to render content visible on the frontend. The default theme which ships with core WordPress (currently "Twenty Fifteen") has been vigorously reviewed and tested for security reasons by both the team of theme developers plus the core development team.
115 | 116 |The default theme can serve as a starting point for custom theme development, and site developers can create a child theme which includes some customization but falls back on the default theme for most functionality and security. The default theme can be easily removed by an administrator if not needed.
117 | 118 |There are approximately 30,000+ plugins and 2,000+ themes listed on the WordPress.org site. These themes and plugins are submitted for inclusion and are manually reviewed by volunteers before making them available on the repository.
121 | 122 |Inclusion of plugins and themes in the repository is not a guarantee that they are free from security vulnerabilities. Guidelines are provided for plugin authors to consult prior to submission for inclusion in the repository17, and extensive documentation about how to do WordPress theme development18 is provided on the WordPress.org site.
123 | 124 |Each plugin and theme has the ability to be continually developed by the plugin or theme owner, and any subsequent fixes or feature development can be uploaded to the repository and made available to users with that plugin or theme installed with a description of that change. Site administrators are notified of plugins which need to be updated via their administration dashboard.
125 | 126 |When a plugin vulnerability is discovered by the WordPress Security Team, they contact the plugin author and work together to fix and release a secure version of the plugin. If there is a lack of response from the plugin author or if the vulnerability is severe, the plugin/theme is pulled from the public directory, and in some cases, fixed and updated directly by the Security Team.
127 |The Theme Review Team is a group of volunteers, led by key and established members of the WordPress community, who review and approve themes submitted to be included in the official WordPress Theme directory. The Theme Review Team maintains the official Theme Review Guidelines19, the Theme Unit Test Data20, and the Theme Check Plugin21, and attempts to engage and educate the WordPress Theme developer community regarding development best practices. Inclusion in the group is moderated by core committers of the WordPress development team.
129 |WordPress can be installed on a multitude of platforms. Though WordPress core software provides many provisions for operating a secure web application, which were covered in this document, the configuration of the operating system and the underlying web server hosting the software is equally important to keep the WordPress applications secure.
131 |WordPress.com is the largest WordPress installation in the world, and is owned and managed by Automattic, Inc., which was founded by Matt Mullenweg, the WordPress project co-creator. WordPress.com runs on the core WordPress software, and has its own security processes, risks, and solutions22. This document refers to security regarding the self-hosted, downloadable open source WordPress software available from WordPress.org and installable on any server in the world.
133 |The WordPress Core Application Programming Interface (API) is comprised of several individual APIs23, each one covering the functions involved in, and use of, a given set of functionality. Together, these form the project interface which allows plugins and themes to interact with, alter, and extend WordPress core functionality safely and securely.
136 | 137 |While each WordPress API provides best practices and standardized ways to interact with and extend WordPress core software, the following WordPress APIs are the most pertinent to enforcing and hardening WordPress security:
138 | 139 |The Database API24, added in WordPress 0.71, provides the correct method for accessing data as named values which are stored in the database layer.
142 | 143 |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.
146 | 147 |It does this through the WP_Filesystem_Base class, and several subclasses which implement different ways of connecting to the local filesystem, depending on individual host support. Any theme or plugin that needs to write files locally should do so using the WP_Filesystem family of classes.
The HTTP API27, added in WordPress 2.728 and extended further in WordPress 2.8, standardizes the HTTP requests for WordPress. The API handles cookies, gzip encoding and decoding, chunk decoding (if HTTP 1.1), and various other HTTP protocol implementations. The API standardizes requests, tests each method prior to sending, and, based on your server configuration, uses the appropriate method to make the request.
152 | 153 |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.
156 |The text in this document (not including the WordPress logo or trademark) is licensed under CC0 1.0 Universal (CC0 1.0) Public Domain Dedication. You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission.
158 | 159 |A special thank you to Drupal's security white paper, which provided some inspiration.
160 |Authored by Sara Rosso
170 | 171 |Contributions from Barry Abrahamson, Michael Adams, Jon Cave, Helen Hou-Sandí , Dion Hulse, Mo Jangda, Paul Maiorana
172 | 173 |Version 1.0 March 2015
174 | 175 |
8 |
9 | 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.
12 | 13 |The information in this document is up-to-date for the latest stable release of the software, WordPress 4.1 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.
14 |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 23% 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.
16 | 17 |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.
18 | 19 |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.
20 | 21 |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.
22 |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 23% of the top 10 million websites1, giving it an estimated 60% market share of all sites using a CMS.
24 | 25 |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":
26 |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.
34 | 35 |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.
36 | 37 |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.
38 | 39 |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.
40 |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.
42 | 43 |A release cycle follows the following pattern2:
44 |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."
53 | 54 |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.
55 | 56 |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.
57 | 58 |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.
60 |The WordPress Security Team is made up of approximately 25 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.
63 | 64 |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.
65 |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 directly via the email address: security@wordpress.org5. The Security Team communicates amongst itself via a private email list, and works on a walled-off, private Trac for tracking, testing, and fixing bugs and security problems.
67 | 68 |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.
69 | 70 |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.
71 | 72 |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.
73 |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.
75 | 76 |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.
77 | 78 |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.
79 |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.
81 | 82 |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.
83 |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.
85 |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.
87 |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 site 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.
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.
93 |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.
95 |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.
97 |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.
99 |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.
101 |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.
103 | 104 |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 in 3.5.2, and a secure fork of SWFUpload was made available by the security team15 for those plugins who continued to use SWFUpload in the short-term.
105 |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.
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.
110 |HTTP requests issued by WordPress are filtered to prevent access to loopback and private IP addresses. Additionally, access is only allowed to certain standard HTTP ports.
112 |WordPress requires a theme to be enabled to render content visible on the frontend. The default theme which ships with core WordPress (currently "Twenty Fifteen") has been vigorously reviewed and tested for security reasons by both the team of theme developers plus the core development team.
115 | 116 |The default theme can serve as a starting point for custom theme development, and site developers can create a child theme which includes some customization but falls back on the default theme for most functionality and security. The default theme can be easily removed by an administrator if not needed.
117 | 118 |There are approximately 30,000+ plugins and 2,000+ themes listed on the WordPress.org site. These themes and plugins are submitted for inclusion and are manually reviewed by volunteers before making them available on the repository.
121 | 122 |Inclusion of plugins and themes in the repository is not a guarantee that they are free from security vulnerabilities. Guidelines are provided for plugin authors to consult prior to submission for inclusion in the repository17, and extensive documentation about how to do WordPress theme development18 is provided on the WordPress.org site.
123 | 124 |Each plugin and theme has the ability to be continually developed by the plugin or theme owner, and any subsequent fixes or feature development can be uploaded to the repository and made available to users with that plugin or theme installed with a description of that change. Site administrators are notified of plugins which need to be updated via their administration dashboard.
125 | 126 |When a plugin vulnerability is discovered by the WordPress Security Team, they contact the plugin author and work together to fix and release a secure version of the plugin. If there is a lack of response from the plugin author or if the vulnerability is severe, the plugin/theme is pulled from the public directory, and in some cases, fixed and updated directly by the Security Team.
127 |The Theme Review Team is a group of volunteers, led by key and established members of the WordPress community, who review and approve themes submitted to be included in the official WordPress Theme directory. The Theme Review Team maintains the official Theme Review Guidelines19, the Theme Unit Test Data20, and the Theme Check Plugin21, and attempts to engage and educate the WordPress Theme developer community regarding development best practices. Inclusion in the group is moderated by core committers of the WordPress development team.
129 |WordPress can be installed on a multitude of platforms. Though WordPress core software provides many provisions for operating a secure web application, which were covered in this document, the configuration of the operating system and the underlying web server hosting the software is equally important to keep the WordPress applications secure.
131 |WordPress.com is the largest WordPress installation in the world, and is owned and managed by Automattic, Inc., which was founded by Matt Mullenweg, the WordPress project co-creator. WordPress.com runs on the core WordPress software, and has its own security processes, risks, and solutions22. This document refers to security regarding the self-hosted, downloadable open source WordPress software available from WordPress.org and installable on any server in the world.
133 |The WordPress Core Application Programming Interface (API) is comprised of several individual APIs23, each one covering the functions involved in, and use of, a given set of functionality. Together, these form the project interface which allows plugins and themes to interact with, alter, and extend WordPress core functionality safely and securely.
136 | 137 |While each WordPress API provides best practices and standardized ways to interact with and extend WordPress core software, the following WordPress APIs are the most pertinent to enforcing and hardening WordPress security:
138 | 139 |The Database API24, added in WordPress 0.71, provides the correct method for accessing data as named values which are stored in the database layer.
142 | 143 |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.
146 | 147 |It does this through the WP_Filesystem_Base class, and several subclasses which implement different ways of connecting to the local filesystem, depending on individual host support. Any theme or plugin that needs to write files locally should do so using the WP_Filesystem family of classes.
The HTTP API27, added in WordPress 2.728 and extended further in WordPress 2.8, standardizes the HTTP requests for WordPress. The API handles cookies, gzip encoding and decoding, chunk decoding (if HTTP 1.1), and various other HTTP protocol implementations. The API standardizes requests, tests each method prior to sending, and, based on your server configuration, uses the appropriate method to make the request.
152 | 153 |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.
156 |The text in this document (not including the WordPress logo or trademark) is licensed under CC0 1.0 Universal (CC0 1.0) Public Domain Dedication. You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission.
158 | 159 |A special thank you to Drupal's security white paper, which provided some inspiration.
160 |Authored by Sara Rosso
170 | 171 |Contributions from Barry Abrahamson, Michael Adams, Jon Cave, Helen Hou-Sandí , Dion Hulse, Mo Jangda, Paul Maiorana
172 | 173 |Version 1.0 March 2015
174 | 175 |
8 |
9 | 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.
12 | 13 |The information in this document is up-to-date for the latest stable release of the software, WordPress 4.1 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.
14 |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 23% 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.
16 | 17 |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.
18 | 19 |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.
20 | 21 |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.
22 |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 23% of the top 10 million websites1, giving it an estimated 60% market share of all sites using a CMS.
24 | 25 |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":
26 |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.
34 | 35 |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.
36 | 37 |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.
38 | 39 |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.
40 |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.
42 | 43 |A release cycle follows the following pattern2:
44 |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."
53 | 54 |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.
55 | 56 |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.
57 | 58 |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.
60 |The WordPress Security Team is made up of approximately 25 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.
63 | 64 |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.
65 |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 directly via the email address: security@wordpress.org5. The Security Team communicates amongst itself via a private email list, and works on a walled-off, private Trac for tracking, testing, and fixing bugs and security problems.
67 | 68 |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.
69 | 70 |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.
71 | 72 |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.
73 |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.
75 | 76 |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.
77 | 78 |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.
79 |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.
81 | 82 |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.
83 |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.
85 |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.
87 |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 site 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.
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.
93 |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.
95 |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.
97 |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.
99 |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.
101 |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.
103 | 104 |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 in 3.5.2, and a secure fork of SWFUpload was made available by the security team15 for those plugins who continued to use SWFUpload in the short-term.
105 |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.
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.
110 |HTTP requests issued by WordPress are filtered to prevent access to loopback and private IP addresses. Additionally, access is only allowed to certain standard HTTP ports.
112 |WordPress requires a theme to be enabled to render content visible on the frontend. The default theme which ships with core WordPress (currently "Twenty Fifteen") has been vigorously reviewed and tested for security reasons by both the team of theme developers plus the core development team.
115 | 116 |The default theme can serve as a starting point for custom theme development, and site developers can create a child theme which includes some customization but falls back on the default theme for most functionality and security. The default theme can be easily removed by an administrator if not needed.
117 | 118 |There are approximately 30,000+ plugins and 2,000+ themes listed on the WordPress.org site. These themes and plugins are submitted for inclusion and are manually reviewed by volunteers before making them available on the repository.
121 | 122 |Inclusion of plugins and themes in the repository is not a guarantee that they are free from security vulnerabilities. Guidelines are provided for plugin authors to consult prior to submission for inclusion in the repository17, and extensive documentation about how to do WordPress theme development18 is provided on the WordPress.org site.
123 | 124 |Each plugin and theme has the ability to be continually developed by the plugin or theme owner, and any subsequent fixes or feature development can be uploaded to the repository and made available to users with that plugin or theme installed with a description of that change. Site administrators are notified of plugins which need to be updated via their administration dashboard.
125 | 126 |When a plugin vulnerability is discovered by the WordPress Security Team, they contact the plugin author and work together to fix and release a secure version of the plugin. If there is a lack of response from the plugin author or if the vulnerability is severe, the plugin/theme is pulled from the public directory, and in some cases, fixed and updated directly by the Security Team.
127 |The Theme Review Team is a group of volunteers, led by key and established members of the WordPress community, who review and approve themes submitted to be included in the official WordPress Theme directory. The Theme Review Team maintains the official Theme Review Guidelines19, the Theme Unit Test Data20, and the Theme Check Plugin21, and attempts to engage and educate the WordPress Theme developer community regarding development best practices. Inclusion in the group is moderated by core committers of the WordPress development team.
129 |WordPress can be installed on a multitude of platforms. Though WordPress core software provides many provisions for operating a secure web application, which were covered in this document, the configuration of the operating system and the underlying web server hosting the software is equally important to keep the WordPress applications secure.
131 |WordPress.com is the largest WordPress installation in the world, and is owned and managed by Automattic, Inc., which was founded by Matt Mullenweg, the WordPress project co-creator. WordPress.com runs on the core WordPress software, and has its own security processes, risks, and solutions22. This document refers to security regarding the self-hosted, downloadable open source WordPress software available from WordPress.org and installable on any server in the world.
133 |The WordPress Core Application Programming Interface (API) is comprised of several individual APIs23, each one covering the functions involved in, and use of, a given set of functionality. Together, these form the project interface which allows plugins and themes to interact with, alter, and extend WordPress core functionality safely and securely.
136 | 137 |While each WordPress API provides best practices and standardized ways to interact with and extend WordPress core software, the following WordPress APIs are the most pertinent to enforcing and hardening WordPress security:
138 | 139 |The Database API24, added in WordPress 0.71, provides the correct method for accessing data as named values which are stored in the database layer.
142 | 143 |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.
146 | 147 |It does this through the WP_Filesystem_Base class, and several subclasses which implement different ways of connecting to the local filesystem, depending on individual host support. Any theme or plugin that needs to write files locally should do so using the WP_Filesystem family of classes.
The HTTP API27, added in WordPress 2.728 and extended further in WordPress 2.8, standardizes the HTTP requests for WordPress. The API handles cookies, gzip encoding and decoding, chunk decoding (if HTTP 1.1), and various other HTTP protocol implementations. The API standardizes requests, tests each method prior to sending, and, based on your server configuration, uses the appropriate method to make the request.
152 | 153 |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.
156 |The text in this document (not including the WordPress logo or trademark) is licensed under CC0 1.0 Universal (CC0 1.0) Public Domain Dedication. You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission.
158 | 159 |A special thank you to Drupal's security white paper, which provided some inspiration.
160 |Authored by Sara Rosso
170 | 171 |Contributions from Barry Abrahamson, Michael Adams, Jon Cave, Helen Hou-Sandí , Dion Hulse, Mo Jangda, Paul Maiorana
172 | 173 |Version 1.0 March 2015
174 | 175 |
8 |
9 | Este documento é uma análise e explicação do desenvolvimento do núcleo do programa do Wordpress e seus processos de segurança relacionados, assim como um exame da segurança inerente construída diretamente no programa. Tomadores de decisão avaliando o WordPress como um sistema de gerenciamento de conteúdo ou como um framework de aplicação web devem usar este documento nas suas análises e tomadas de decisão, e para desenvolvedores se referirem a ele para se familiarizarem com os componentes de segurança e as boas práticas do programa.
12 | 13 |A informação neste documento é atualizada para o lançamento estável mais recente do programa, WordPress 4.1 no momento da publicação, mas deve ser considerada relevante também para as versões mais recente do programa como a compatibilidade com versões anteriores é um forte foco para o time de desenvolvimento do WordPress. Medidas específicas de segurança e mudanças serão notadas como elas foram adicionadas ao núcleo do programa nos lançamentos específicos. É fortemente encorajado para sempre estar rodando a última versão estável do WordPress para garantir a experiência mais segura possível. 14 |
15 |O WordPress é um sistema de gerenciamento de conteúdo dinâmico e de código-fonte aberto que é usado para dar força a milhões de sites, aplicações web, e blogs. Ele atualmente da força para mais de 23% dos top 10 milhões de websites na internet. A usabilidade, extensibilidade do WordPress, e maturidade da comunidade de desenvolvimento fazem dele uma popular e segura escolha para websites de todos os tamanhos.
17 | 18 |Desde o início em 2003, WordPress tem sofrido um contínuo amadurecimento para que o núcleo do seu programa possa enfrentar e mitigar ameaças de segurança comuns, includindo a lista das Top 10 identificadas pelo The Open Web Application Security Project (OWASP) como vulnerabilidades de segurança comuns, que serão discutidas neste documento.
19 | 20 |O Time de Segurança do Wordpress, em colaboração com o Time de Liderança do Núcleo do WordPress e apoiado pela comunidade global do Wordpress, trabalham para identificar e resolver questões de segurança no núcleo do programa disponível para distribuição e instalação em WordPress.org, assim como recomendando e documentando boas práticas de segurança para plugin de terceiros e autores de theme.
21 | 22 |Desenvolvedores e adminstradores de sites devem prestar atenção em particular para o uso correto das APIs do núcleo, e na configuração do servidor subjacente o qual tem sido fonte de vulnerabilidades comuns, assim como assegurando que todos os usuários empreguem senhas fortes para acessar o Wordpress.
23 |Wordpress um sistema de gerenciamento de conteúdo (do inglês Content Management System – CMS) de código-fonte aberto e gratuito. É o programa CMS mais utilizado no mundo e ele alimenta mais de 23% dos top 10 milhões dos sites1, dando-lhe uma estimativa de 60% da quota de mercado de todos os sites usando um CMS.
25 | 26 |Wordpress é licencisado sobre a Licença Pública Geral (do inglês General Public License - GPL) (GPLv2 ou posterior) que prevê quatro liberdades fundamentais, e que podem ser consideradas como a "declaração de direitos" do Wordpress:
27 |O projeto Wordpress é uma meritocracia, gerido pelo time de liderança do núcleo, e liderado pelo seu co-criador e desenvolvedor líder, Matt Mullenweg. O time governa todos os aspectos do projeto, incluíndo desenvolvimento do núcleo, Wordpress.org, e iniciativas da comunidade.
35 | 36 |O Time de Liderança do Núcleo consiste de Matt Mullenweg, cinco desenvolvedores líder, e mais de uma dúzia de desenvolvedores do núcleo com acesso permanente para comitar. Estes desenvolvedores tem autoridade final em decisões técnicas, e lideram discussões sobre arquitetura e esforços de implementação.
37 | 38 |Wordpress tem um número de desenvolvedores contribuintes. Alguns destes são ex ou atuais comitadores, e alguns são possíveis comitadores futuros. Estes desenvolvedores contribuintes são confiáveis e contribuidores veteranos para o Wordpress os quais ganharam grande respeito entre seus pares. Conforme necessário, WordPress também tem comitadores convidados, indivíduos que são concedidos acesso à comitar, algumas vezes para um componente específico, temporariamente ou a título de experiência.
39 | 40 |Os desenvolvedores do núcleo e contribuintes orientam principalmente o desenvolvimento do Wordpress. A cada vesão, centenas de desenvolvedores contribuem código para o Wordpress. Estes contribuintes do núcleo são voluntários que contribuem para a base de código do núcleo de alguma maneira.
41 |Cada ciclo de lançamento do WordPress é liderado por um ou mais dos principais desenvolvedores do WordPress. Um ciclo de lançamento geralmente dura cerca de 4 meses, a partir da reunião inicial de escopo até o lançamento da nova versão.
43 | 44 |A release cycle follows the following pattern2:
45 |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."
54 | 55 |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.
56 | 57 |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.
58 | 59 |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.
61 |The WordPress Security Team is made up of approximately 25 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.
64 | 65 |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.
66 |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 directly via the email address: security@wordpress.org5. The Security Team communicates amongst itself via a private email list, and works on a walled-off, private Trac for tracking, testing, and fixing bugs and security problems.
68 | 69 |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.
70 | 71 |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.
72 | 73 |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.
74 |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.
76 | 77 |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.
78 | 79 |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.
80 |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.
82 | 83 |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.
84 |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.
86 |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.
88 |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 site 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.
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.
94 |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.
96 |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.
98 |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.
100 |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.
102 |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.
104 | 105 |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 in 3.5.2, and a secure fork of SWFUpload was made available by the security team15 for those plugins who continued to use SWFUpload in the short-term.
106 |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.
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.
111 |HTTP requests issued by WordPress are filtered to prevent access to loopback and private IP addresses. Additionally, access is only allowed to certain standard HTTP ports.
113 |WordPress requires a theme to be enabled to render content visible on the frontend. The default theme which ships with core WordPress (currently "Twenty Fifteen") has been vigorously reviewed and tested for security reasons by both the team of theme developers plus the core development team.
116 | 117 |The default theme can serve as a starting point for custom theme development, and site developers can create a child theme which includes some customization but falls back on the default theme for most functionality and security. The default theme can be easily removed by an administrator if not needed.
118 | 119 |There are approximately 30,000+ plugins and 2,000+ themes listed on the WordPress.org site. These themes and plugins are submitted for inclusion and are manually reviewed by volunteers before making them available on the repository.
122 | 123 |Inclusion of plugins and themes in the repository is not a guarantee that they are free from security vulnerabilities. Guidelines are provided for plugin authors to consult prior to submission for inclusion in the repository17, and extensive documentation about how to do WordPress theme development18 is provided on the WordPress.org site.
124 | 125 |Each plugin and theme has the ability to be continually developed by the plugin or theme owner, and any subsequent fixes or feature development can be uploaded to the repository and made available to users with that plugin or theme installed with a description of that change. Site administrators are notified of plugins which need to be updated via their administration dashboard.
126 | 127 |When a plugin vulnerability is discovered by the WordPress Security Team, they contact the plugin author and work together to fix and release a secure version of the plugin. If there is a lack of response from the plugin author or if the vulnerability is severe, the plugin/theme is pulled from the public directory, and in some cases, fixed and updated directly by the Security Team.
128 |The Theme Review Team is a group of volunteers, led by key and established members of the WordPress community, who review and approve themes submitted to be included in the official WordPress Theme directory. The Theme Review Team maintains the official Theme Review Guidelines19, the Theme Unit Test Data20, and the Theme Check Plugin21, and attempts to engage and educate the WordPress Theme developer community regarding development best practices. Inclusion in the group is moderated by core committers of the WordPress development team.
130 |WordPress can be installed on a multitude of platforms. Though WordPress core software provides many provisions for operating a secure web application, which were covered in this document, the configuration of the operating system and the underlying web server hosting the software is equally important to keep the WordPress applications secure.
132 |WordPress.com is the largest WordPress installation in the world, and is owned and managed by Automattic, Inc., which was founded by Matt Mullenweg, the WordPress project co-creator. WordPress.com runs on the core WordPress software, and has its own security processes, risks, and solutions22. This document refers to security regarding the self-hosted, downloadable open source WordPress software available from WordPress.org and installable on any server in the world.
134 |The WordPress Core Application Programming Interface (API) is comprised of several individual APIs23, each one covering the functions involved in, and use of, a given set of functionality. Together, these form the project interface which allows plugins and themes to interact with, alter, and extend WordPress core functionality safely and securely.
137 | 138 |While each WordPress API provides best practices and standardized ways to interact with and extend WordPress core software, the following WordPress APIs are the most pertinent to enforcing and hardening WordPress security:
139 | 140 |The Database API24, added in WordPress 0.71, provides the correct method for accessing data as named values which are stored in the database layer.
143 | 144 |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.
147 | 148 |It does this through the WP_Filesystem_Base class, and several subclasses which implement different ways of connecting to the local filesystem, depending on individual host support. Any theme or plugin that needs to write files locally should do so using the WP_Filesystem family of classes.
The HTTP API27, added in WordPress 2.728 and extended further in WordPress 2.8, standardizes the HTTP requests for WordPress. The API handles cookies, gzip encoding and decoding, chunk decoding (if HTTP 1.1), and various other HTTP protocol implementations. The API standardizes requests, tests each method prior to sending, and, based on your server configuration, uses the appropriate method to make the request.
153 | 154 |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.
157 |The text in this document (not including the WordPress logo or trademark) is licensed under CC0 1.0 Universal (CC0 1.0) Public Domain Dedication. You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission.
159 | 160 |A special thank you to Drupal's security white paper, which provided some inspiration.
161 |Authored by Sara Rosso
171 | 172 |Contributions from Barry Abrahamson, Michael Adams, Jon Cave, Helen Hou-Sandí , Dion Hulse, Mo Jangda, Paul Maiorana
173 | 174 |Version 1.0 March 2015
175 | 176 |
8 |
9 | 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 familiarise themselves with the security components and best practices of the software.
12 | 13 |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.
14 |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 43% 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.
16 | 17 |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.
18 | 19 |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.
20 | 21 |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.
22 |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 43% of the top 10 million websites1, giving it an estimated 63% market share of all sites using a CMS.
24 | 25 |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":
26 |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.
34 | 35 |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.
36 | 37 |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.
38 | 39 |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.
40 |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.
42 | 43 |A release cycle follows the following pattern2:
44 |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."
53 | 54 |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.
55 | 56 |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.
57 | 58 |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.
60 |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.
63 | 64 |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.
65 |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.
67 | 68 |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.
69 | 70 |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.
71 | 72 |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.
73 |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.
75 | 76 |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.
77 | 78 |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.
79 |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 organisations. The Top 10 items are selected and prioritised in combination with consensus estimates of exploitability, detectability, and impact estimates.
81 | 82 |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.
83 |There is a set of functions and APIs available in WordPress to assist developers in making sure unauthorised code cannot be injected, and help them validate and sanitise data. Best practices and documentation are available9 on how to use these APIs to protect, validate, or sanitise 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.
85 |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.
87 |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.
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 unauthorised requests.
93 |The majority of the WordPress security configuration operations are limited to a single authorised 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.
95 |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.
97 |WordPress checks for proper authorisation and permissions for any function level access requests prior to the action being executed. Access or visualisation of administrative URLs, menus, and pages without proper authentication is tightly integrated with the authentication system to prevent access from unauthorised users.
99 |WordPress uses cryptographic tokens, called nonces13, to validate intent of action requests from authorised 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.
101 |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.
103 | 104 |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 team15 for those plugins who continued to use SWFUpload in the short-term.
105 |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.
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.
110 |HTTP requests issued by WordPress are filtered to prevent access to loopback and private IP addresses. Additionally, access is only allowed to certain standard HTTP ports.
112 |WordPress requires a theme to be enabled to render content visible on the frontend. The default theme which ships with core WordPress (currently "Twenty Fifteen") has been vigorously reviewed and tested for security reasons by both the team of theme developers plus the core development team.
115 | 116 |The default theme can serve as a starting point for custom theme development, and site developers can create a child theme which includes some customisation but falls back on the default theme for most functionality and security. The default theme can be easily removed by an administrator if not needed.
117 | 118 |There are approximately 50,000+ plugins and 4,500+ themes listed on the WordPress.org site. These themes and plugins are submitted for inclusion and are manually reviewed by volunteers before making them available on the repository.
121 | 122 |Inclusion of plugins and themes in the repository is not a guarantee that they are free from security vulnerabilities. Guidelines are provided for plugin authors to consult prior to submission for inclusion in the repository17, and extensive documentation about how to do WordPress theme development18 is provided on the WordPress.org site.
123 | 124 |Each plugin and theme has the ability to be continually developed by the plugin or theme owner, and any subsequent fixes or feature development can be uploaded to the repository and made available to users with that plugin or theme installed with a description of that change. Site administrators are notified of plugins which need to be updated via their administration dashboard.
125 | 126 |When a plugin vulnerability is discovered by the WordPress Security Team, they contact the plugin author and work together to fix and release a secure version of the plugin. If there is a lack of response from the plugin author or if the vulnerability is severe, the plugin/theme is pulled from the public directory, and in some cases, fixed and updated directly by the Security Team.
127 |The Theme Review Team is a group of volunteers, led by key and established members of the WordPress community, who review and approve themes submitted to be included in the official WordPress Theme directory. The Theme Review Team maintains the official Theme Review Guidelines19, the Theme Unit Test Data20, and the Theme Check Plugin21, and attempts to engage and educate the WordPress Theme developer community regarding development best practices. Inclusion in the group is moderated by core committers of the WordPress development team.
129 |WordPress can be installed on a multitude of platforms. Though WordPress core software provides many provisions for operating a secure web application, which were covered in this document, the configuration of the operating system and the underlying web server hosting the software is equally important to keep the WordPress applications secure.
131 |WordPress.com is the largest WordPress installation in the world, and is owned and managed by Automattic, Inc., which was founded by Matt Mullenweg, the WordPress project co-creator. WordPress.com runs on the core WordPress software, and has its own security processes, risks, and solutions22. This document refers to security regarding the self-hosted, downloadable open source WordPress software available from WordPress.org and installable on any server in the world.
133 |The WordPress Core Application Programming Interface (API) is comprised of several individual APIs23, each one covering the functions involved in, and use of, a given set of functionality. Together, these form the project interface which allows plugins and themes to interact with, alter, and extend WordPress core functionality safely and securely.
136 | 137 |While each WordPress API provides best practices and standardised ways to interact with and extend WordPress core software, the following WordPress APIs are the most pertinent to enforcing and hardening WordPress security:
138 | 139 |The Database API24, added in WordPress 0.71, provides the correct method for accessing data as named values which are stored in the database layer.
142 | 143 |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.
146 | 147 |It does this through the WP_Filesystem_Base class, and several subclasses which implement different ways of connecting to the local filesystem, depending on individual host support. Any theme or plugin that needs to write files locally should do so using the WP_Filesystem family of classes.
The HTTP API27, added in WordPress 2.728 and extended further in WordPress 2.8, standardises the HTTP requests for WordPress. The API handles cookies, gzip encoding and decoding, chunk decoding (if HTTP 1.1), and various other HTTP protocol implementations. The API standardizes requests, tests each method prior to sending, and, based on your server configuration, uses the appropriate method to make the request.
152 | 153 |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 unauthorised users accessing or performing functions beyond their permitted capabilities.
156 |The text in this document (not including the WordPress logo or trademark) is licensed under CC0 1.0 Universal (CC0 1.0) Public Domain Dedication. You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission.
158 | 159 |A special thank you to Drupal's security white paper, which provided some inspiration.
160 |Authored by Sara Rosso
170 | 171 |Contributions from Barry Abrahamson, Michael Adams, Jon Cave, Helen Hou-Sandí, Dion Hulse, Mo Jangda, Paul Maiorana
172 | 173 |Version 1.0 March 2015
174 | 175 |
8 |
9 | このドキュメントは、WordPress コアソフトウェアの開発とそれに関連するセキュリティプロセスの分析と説明だけでなく、ソフトウェアに直接組み込まれる固有のセキュリティの調査でもあります。コンテンツ管理システムや Web アプリケーションフレームワークとして WordPress を評価する立場にある意思決定者は、自分の分析と意思決定にこの文書を利用するべきであり、開発者は、この白書を参照してこのセキュリティコンポーネントとこのソフトウェアのベストプラクティスに習熟するべきです。
12 | 13 |この文書に記載されている情報は、この白書公開時の最新安定版ソフトウェア、WordPress 4.1 の最新版のものですが、WordPress 開発チームは後方互換性に最大限の注意を払っているので、直近のこのソフトウェアのいくつかのバージョンでも関連するものと考えてください。特定のセキュリティ対策と変更は、コアソフトウェアの特定のリリースで追加されたものとして言及されます。可能な限りの安全性を確保するため、常に WordPress の最新安定版を利用するよう強くおすすめします。
14 |WordPress は、非常に多数のウェブサイト、ウェブアプリケーション、ブログを動かすために使われている動的なオープンソースのコンテンツ管理システムです。現時点では、インターネット上のトップ1千万ウェブサイトのうち43％以上で利用されています。WordPress の使いやすさ、拡張性、および成熟した開発コミュニティによって WordPress は普及し、あらゆる規模のウェブサイトのための安全な選択肢となっています。
16 | 17 |WordPress は2003年のその始まりから継続して堅牢化され続けているので、このコアのソフトウェアは一般的なセキュリティーの脅威に対処したりそれを軽減したりできます。 このセキュリティの脅威には Open Web Application Security Project によって一般的なセキュリティの脆弱性として識別されているトップ10のものも含まれ、この文書でまた考察いたします。
18 | 19 |WordPress のセキュリティチームは、WordPress のコアリーダーシップチームと共同で、また WordPress のグローバルコミュニティに支えられ、WordPress.org で配布され、インストールされるコアソフトウェアのセキュリティ問題を特定、解決すべく尽力しています。同様にまた、第三者のプラグインとテーマ作成者のためにセキュリティのベストプラクティスを推奨したり文書化したりしています。
20 | 21 |サイトの開発者および管理者のみなさんは、コア API の正しい利用と一般的な脆弱性の源となってきているサーバーの設定には特別な注意を払うようにし、また同様に、WordPress にアクセスするためのパスワードに強力なものを利用するようにすべてのユーザーに対して確実を期すべきです。
22 |WordPress は、フリー (訳注: ここでは無料かつ自由の意味) なオープンソースのコンテンツ管理システム (CMS) です。これは世界で最も広く使用されている CMS ソフトウェアであり、トップ1千万のうちの43％以上1のウェブサイトを動かしていて、CMS を使用しているすべてのサイトの63％の市場シェアを占めると推定されます。
24 | 25 |WordPress はコアとなる4つの自由を提供する一般公衆利用許諾契約書 (GPLv2 もしくはそれ以降）の下でライセンスされており、それはまた WordPress の「権利章典」と考えることができます:
26 |WordPress のプロジェクトは実力主義で、コアリーダーシップチームによって運営され、その共同創始者でありリード開発者のマット·マレンウェッグに率いられています。このチームは、コア開発、WordPress.org、およびコミュニティへの主導権など、このプロジェクトのすべての側面を統制しています。
34 | 35 |このコアリーダーシップチームは、マット·マレンウェッグ、5人のリード開発者、および1ダース以上の恒久的なコミットアクセスを持つコア開発者によって構成されています。これらの開発者は、技術的判断に関する最終的な権限を持っていて、アーキテクチャに関する議論と実装の取り組みをリードしています。
36 | 37 |WordPress には寄与してくれるたくさんの開発者がいます。こうした開発者の中には以前の、もしくは現行のコミッターがいたり、あるいは将来的にコミッターとなる可能性の高い方もいたりします。こうした貢献開発者は信頼され、WordPress へのベテランの貢献者は仲間の間で大いに尊敬を得ています。WordPress にはまた、必要に応じたゲストコミッターがいます。コミットアクセスを許可された個人で、時には特定のコンポーネントのために一時的もしくは実験的な場合もあります。
38 | 39 |こうしたコア開発者と寄与開発者が WordPress の開発を主にリードしています。各バージョンで数百人もの開発者が WordPress にコードを寄与してくれています。これらのコアコントリビューターは何らかの方法でコアのコードベースに寄与するボランティアです。
40 |WordPress のそれぞれのリリースサイクルは、一人もしくは複数の WordPress のコア開発者がリードします。一つのリリースサイクルは通常、最初の開発範囲選考ミーティングからそのバージョンのリリースまで、約4ヶ月です。
42 | 43 |リリースサイクルは、以下のパターン2にしたがいます:
44 |WordPress のメジャーバージョンは最初の二つの数字によって決定されます。たとえば、3.5はメジャーリリースで、3.6、3.7、4.0もまた、メジャーリリースです。「WordPress 3」または「WordPress 4」は存在しません。各メジャーリリースはその番号付け、例えば「WordPress 3.9」と言及されます。
53 | 54 |メジャーリリースでは、新しいユーザー向けの機能と開発者開発者向けの API を追加することがあります。ソフトウェアの世界では通常、「メジャー」バージョンというのは後方互換性なくすこともできることを意味しますが、WordPress は後方互換性を保つよう努めています。開発者にとっても同様ですが、ユーザーにとってもアップデートをより簡単な事にするため、後方互換性というのはこのプロジェクトにとってもっとも重要な理念の一つです。
55 | 56 |WordPress のマイナーバージョンは3番目の数字によって決まります。バージョン3.5.1はマイナーリリースで、3.4.2もまた同様にマイナーリリースです3 。マイナーリリースは、セキュリティ脆弱性の修正と重大なバグの対処のみに限定されます。WordPress の新しいバージョンがこのように頻繁にリリースされているので - 目標としてはメジャーリリースが4〜5ヶ月ごと、マイナーリリースは必要に応じて - 必要となるのはメジャーとマイナーリリースのみです。
57 | 58 |WordPress のプロジェクトは、後方互換性への強い信念を持っています。この信念はつまり、WordPress のコアソフトウェアがアップデートされてもテーマ、プラグイン、およびカスタムなコードが機能し続けるという意味であり、それによりまた、サイトのオーナーに自分たちの WordPress バージョンを最新の安全なリリースのバージョンに保つように促すことにもなります。
60 |WordPress のセキュリティチームは、リード開発者やセキュリティ研究者など約25名の専門家で構成されています。そのうち約半分は Automattic (ウェブ上ではもっとも古くからあり、かつ最大の 63 | WordPress ホスティングプラットフォーム) の従業員であり、多くがウェブセキュリティの分野で働いています。このチームはよく知られていて信頼できるセキュリティ研究者やホスティング会社3 と情報交換しています。
64 | 65 |WordPress のセキュリティチームは、しばしば他のセキュリティチームと協力して、共通に依存するプログラムの問題に対処します。例えば、WordPress 3.9.2 4での、WordPress に同梱の XML-RPC API によって使用されていた PHP XML パーサの脆弱性問題などです。この脆弱性の解決は、WordPress と Drupal のセキュリティチームの共同の努力の結果でした。
66 |WordPress のセキュリティチームは、あらゆる潜在的な脆弱性をただちにセキュリティチームに警告することによる責任ある開示を信じています。潜在的なセキュリティの脆弱性は、メールアドレス: security@wordpress.org5 経由でセキュリティチームに直接通知することができます。セキュリティチームは、プライベートなメールリストを経由してチーム内で相談し、隔離されたプライベートな Trac 上でバグやセキュリティ問題を追跡、テスト、解決の作業を行っています。
68 | 69 |各セキュリティレポートは受信次第確認され、チームはその脆弱性の検証およびその重大度を決定するための作業をします。問題が確認された場合、重大度に応じて、WordPress ソフトウェアの今後のリリースに取り入れることができる、もしくはセキュリティリリースとして即時に公開できるその問題を解消するためのパッチをセキュリティチームは計画します。
70 | 71 |即時のセキュリティリリースでは、セキュリティチームによってそのリリースと変更の詳細について告知する注意勧告が WordPress.org ニュースサイト6に公開されます。その注意勧告の中では、将来的にも引き続き責任ある報告を奨励し促進するため、脆弱性の責任ある開示のためのクレジットが与えられます。
72 | 73 |WordPress ソフトウェアの管理者には、新しいリリースが公開されるとアップグレードするため通知が自分のサイトのダッシュボードに表示され、手動でアップグレードすると、そのリリースでの変更の詳細が記載された「WordPress について」の画面にリダイレクトされます。管理者が自動バックグラウンド更新を有効にしている場合は、アップグレード完了後にメールを受け取ります。
74 |バージョン3.7以降、3.7.1や3.7.2のようなすべてのマイナーリリース7のための自動化されたバックグラウンド更新機能を WordPress は導入しました。WordPress のセキュリティチームは問題を特定、修正し、WordPress のための自動化されたセキュリティ強化を送り出すことができ、サイトの所有者は自分たちの側では何もする必要はなく、セキュリティ更新は自動的にインストールされます。
76 | 77 |セキュリティ更新プログラムがその時点の WordPress 安定版リリースのためにプッシュされると、バックグラウンド更新が可能なすべてのバージョン (WordPress 3.7以上) に対してもセキュリティ更新をプッシュします。そのため、こうした WordPress の古くても最近のバージョンであれば、セキュリティ更新を受けることができます。
78 | 79 |個々のサイト所有者は、設定ファイル内の単純な変更によって自動バックグラウンド更新プログラムの無効化を選択できますが、この機能の有効化の維持および WordPress 最新安定版の使用をコアチームは強く推奨しています。
80 |オープンウェブアプリケーションセキュリティプロジェクト (OWASP) は、ウェブアプリケーションのセキュリティに特化したオンラインコミュニティです。OWASP トップ10リスト8は、幅広い組織にとって最も深刻なアプリケーションセキュリティ上のリスクを特定することに焦点を当てています。トップ10の項目は、悪用のされやすさ、検出可能性、そして推定されるインパクトのコンセンサス予想の組み合わせにより選択、優先順位付けされます。
82 | 83 |次のセクションでは、これらの潜在的なリスクに対してコアソフトウェアおよびサードパーティのプラグインとテーマを強化するために WordPress が使用している API、リソース、およびポリシーについて考察します。
84 |WordPress には、許可されていないコードが確実に挿入されないようにするために開発者を支援したり、開発者がデータをバリデートおよびサニタイズする手助けをしたりする関数や API のセットがあります。HTML、URL、そして HTTP ヘッダー内の入出力データを守り、バリデートし、サニタイズするためにこれらの API をどのように使うか、データベースおよびファイルシステムとのやりとりをする時のベストプラクティスおよびドキュメントが利用可能です9。また管理者は、フィルタを介してアップロードできるファイルの種類をさらに制限することができます。
86 |WordPress のコアソフトウェアは、ユーザー ID、名前、パスワードなどのユーザーアカウントおよび認証を、認証クッキーと同様にサーバー側で管理しています。パスワードは、標準的なソルティングおよび延伸技術を使用してデータベースに保護されます。WordPress のバージョン4.0以降では、 既存のセッションはログアウト時に破棄されます。
88 |WordPress は、ユーザーの入力したデータが安全であることを保証するのを助けることのできる様々な機能を提供しています10 。信頼の置けるユーザー、シングル WordPress の場合では管理者権限と編集者権限、マルチサイト WordPress の場合は特権管理者権限のユーザーのみ、投稿や固定ページ内などでフィルタリングされていない HTML や JavaScript を必要なときに投稿することができます。信頼されていないユーザーによって送信されたコンテンツは、デフォルトでフィルタリングされ、wp_kses関数を通じた KSES ライブラリを利用して危険なエンティティを削除されます。
例として、関数 the_search_query() が多くのテーマ作者によって誤って利用されていて、彼らがこの関数の出力をエスケープせずに HTML 内で利用していることに WordPress のコアチームは WordPress 2.3のリリース前に気づきました。極めてまれに後方互換性を損なうかもしれませんでしたが、WordPress 2.3ではこの関数の出力が予めエスケープされたものへと変更されました。
WordPress は、URL やフォームのフィールド内で利用可能なユーザーアカウントやコンテツの一意の数値識別子など、直接的なオブジェクト参照をしばしば提供しています。これらの識別子は直接的なシステム情報を開示していますが、WordPress の豊富なアクセス権とアクセス制御システムにより、許可されていないリクエストは阻まれています。
94 |WordPress のセキュリティ設定操作の大部分は、管理者権限のみに制限されています。WordPress のデフォルト設定はコアチームのレベルで継続的に評価されています。また、WordPress のコアチームは、WordPress サイトを稼働させるサーバー構成のセキュリティを強化するためのドキュメントやベストプラクティスを提供しています11。
96 |WordPress のユーザーアカウントのパスワードはソルト化され、ポータブル PHP パスワードハッシュングフレームワークに基づいてハッシュ化されています12。WordPress のパーミッションシステムは、登録者ユーザーの個人情報、コメント送信者のメールアドレス、非公開コンテンツなどのプライベートな情報へのアクセスコントロールに利用されています。WordPress 3.7 では、コアのソフトウェアにパスワード強度メーターが導入され、ユーザーがパスワードを設定するための付加的な情報と強度を増すためのヒントを提供しています。WordPress はまた、HTTPS を要求するための設定オプションも持っています。
98 |WordPress は、関数レベルのすべてのアクセス要求に対して、そのアクションが実際に実行される前に、認証と権限が適切かどうかをチェックします。管理用のURLやメニュー、そしてページへの適切な認証なしでのアクセスまたは可視化は、権限のないユーザーからのアクセスを防止するために認証システムとしっかりと統合されています。
100 |WordPress はナンス13と呼ばれる暗号化トークンを使用して、潜在的な CSRF の脅威から保護するために許可されたユーザーからのアクション要求の意図をバリデートします。WordPress は一意で一時的なトークンの生成および検証のための API を提供しています。このトークンは特定のユーザー、特定のアクション、特定のオブジェクト、特定の期間に制限され、必要に応じてフォームや URL 付加することができます。さらに、すべてのナンスはログアウト時に無効化されます。
102 |WordPress のコアチームは、コア機能のために WordPress に含まれているライブラリや統合されているフレームワークのいくつかを密接にモニターしています。コアチームはこれまでも、 104 | WordPress 3.5.214における TinyMCE でのクロスサイトの脆弱性を修正するためのアップデートなど、こうしたサードパーティ製コンポーネントをより安全にするための貢献をいくつか行っています。
105 | 106 |コアチームは必要に応じて重要な外部コンポーネントをフォークしたり入れ替えたりします。例えば、3.5.2では、SWFUpload ライブラリが Plupload と公式に入れ替えられ、短期的に SWFUpload を使い続けるプラグイン用に SWFUpload の安全なフォークバージョンがセキュリティチームによって提供されました15。
107 |WordPress の内部のアクセス制御や認証システムは、ユーザーを望まないサイトへ導いたり、自動リダイレクトしたりする試みから保護します。この機能は、API の wp_safe_redirect() 16 を介してプラグイン開発者でも利用可能です。
XML を処理する場合、WordPress は外部エンティティとエンティティ拡張攻撃の両方を防ぐためにカスタムな XML エンティティの読み込みを無効にします。WordPress は、プラグインの作成者向けには PHP のコア機能以上のさらなる安全な XML 処理用 API は提供していません。
112 |WordPress によって発行された HTTP リクエストは、ループバックおよびプライベート IP アドレスへのアクセスを防止するためにフィルタリングされています。さらに、アクセスは特定の標準な HTTP ポートにのみに限定されています。
114 |WordPress は、フロントエンド上でコンテンツをレンダリングして表示させるためのテーマを必要とします。デフォルトのテーマ (現在は「Twenty Fifteen」) は WordPress コアに付属していて、セキュリティ上の理由からテーマ開発者チームに加えてコア開発チームと両方によって積極的にレビューされ、テストされています。
117 | 118 |デフォルトのテーマは、カスタムテーマ開発のための出発点として役立てるこことができます。サイト開発者は、いくつかのカスマイズを含めつつも、機能と安全性のほとんどをこのデフォルトテーマに頼る子テーマを作成することができます。必要でない場合は、管理者はデフォルトテーマを簡単に削除することができます。
119 | 120 |WordPress.org サイトには約30,000以上のプラグインと約2,000以上のテーマが掲載されています。これらのテーマやプラグインは掲載のため提出され、リポジトリでそれらが利用可能になる前にボランティアによって手動でレビューされます。
123 | 124 |このリポジトリにプラグインやテーマが入るということは、これらのプラグインやテーマがセキュリティの脆弱性から免れていることを保証するわけではありません。このリポジトリに入れてもらうための申し込み前にプラグイン作成者が参考にするガイドライン17と、どのように WordPress のテーマ開発を行うかに関する広範囲なドキュメント18が WordPress.org サイトで提供されています。
125 | 126 |各プラグインとテーマは、そのプラグインやテーマの所有者によって継続的に開発され、その後の修正や機能開発がリポジトリにアップロードされ、その変更の説明と一緒にそのプラグインやテーマをユーザーが利用可能になれるようになっています。サイト管理者には、その管理用のダッシュボードを介して更新する必要があるプラグインが通知されます。
127 | 128 |プラグインの脆弱性が WordPress セキュリティチームによって発見された場合、チームはそのプラグインの作成者に連絡し、そのプラグインの安全なバージョンのための修正とリリースに協力します。そのプラグインの作成者からの応答がない場合、またはその脆弱性が重大な場合には、そのプラグイン/テーマは公開ディレクトリから取り除かれ、場合によってはセキュリティチームによって直接修正、更新されます。
129 |テーマレビューチームはボランティアのグループで、WordPress コミュニティから認められ、キーとなるメンバーによってリードされて、彼らにより公式の WordPress テーマディレクトリ掲載のために申請されたテーマをレビューされ、承認されます。テーマレビューチームは、公式テーマレビューガイドライン19、テーマユニットテストデータ20、テーマチェックプラグイン21のメンテナンスを行っています。また、テーマ開発のベストプラクティスに関する WordPress のテーマ開発者コミュニティの参加、教育に取り組もうとしています。このグループへの参加は WordPress 開発チームのコアコミッターたちによってモデレートされています。
131 |WordPress は多数のプラットフォームにインストールすることができます。WordPress のコアソフトウェアでは、このドキュメントでカバーされている安全なウェブアプリケーションの運営のため多くの対策を提供していますが、このソフトウェアをホストするオペレーティングシステムや基盤となるウェブサーバーの設定もまた WordPress を安全に保つために同じように重要です。
133 |WordPress.com は WordPress の設置数として世界最大で、WordPress プロジェクトの共同創始者でもあるマット·マレンウェッグによって設立され Automattic によって所有および管理されています。WordPress.com は、WordPress コアソフトウェア上で動作し、独自のセキュリティプロセス、リスク、およびソリューションを持っています22 。この文書は、自分で運営するタイプ、WordPress.org からダウンロード可能で世界中のどのサーバーにもインストール可能なオープンソースの WordPress に関するセキュリティについてのものです。
135 |WordPress コアのアプリケーションプログラミングインターフェイス (API) は、いくつかの個別の API 23で構成され、それぞれ関係する関数、利用、与えられている一連の機能をカバーしています。それとともに、プラグインやテーマが安全確実に WordPress コア機能とのやり取りやその変更、そして拡張をできるようにしているこのプロジェクトのインターフェイスを形作っています。
138 | 139 |それぞれの WordPress API はベストプラクティスと WordPress コアソフトウェアを拡張するための標準化された方法を提供していますが、WordPress のセキュリティを強化し堅牢化するためにもっとも関連するのが次の WordPress API です:
140 | 141 |WordPress 0.71 で実装されたデータベース API24 は、データベースに格納されているデータに、名前付きの値としてアクセスするための正しい方法を提供します。
144 | 145 |WordPress 2.626 で追加されたファイルシステム API25 は、もともと WordPress 独自の自動更新機能のために作られました。ファイルシステム API は、さまざまな種類のホスト上でファイルシステムにローカルファイルを安全に読み取り・書き込みするために必要な機能を抽象化しています。
148 | 149 |これは WP_Filesystem_Base クラスおよびいくつかのサブクラスを通じて行われ、個々のホストサポートに応じてローカルファイルシステムに接続するためのさまざまな方法を実装しています。ローカルのファイルに書き込む必要があるテーマやプラグインは、WP_Filesystemファミリのクラスを使用してそれを行うようにします。
WordPress 2.7 28で追加され、WordPress 2.8でさらに拡張された HTTP API 27は、WordPress の HTTP リクエストを標準化しています。この API は、クッキー、gzip 圧縮符号化及び復号化、チャンクデコード (HTTP 1.1の場合)、およびその他の種々の HTTP プロトコル実装を処理します。この API は、リクエストを標準化し、送信する前に各メソッドをテストし、サーバー設定に基づいてリクエストを生成するために適切な方法を使用します。
154 | 155 |権限と現在のユーザー API 29 は、要求されている任意のタスクまたは操作を実行するために現在のユーザーのアクセス権や権限を確認するのに役立つ関数の集合であり、ユーザーが許可されていない機能にアクセスしたり、実行したりすることに対する保護をさらに強化できます。
158 |この文書内のテキスト (WordPress のロゴおよび商標を除く) は、CC0 1.0 Universal (CC0 1.0) Public Domain Dedication のもとにライセンスされています。利用者は許可を求める必要なく、商業目的であっても作品の複製・変更・配布・実行を行うことができます。
160 | 161 |この資料を作成するにあたってインスピレーションを与えてくれた Drupal セキュリティ白書に感謝します。 162 |
163 |執筆: サラ・ロッソ
173 | 174 |バリー・エイブラハムソン、マイケル・アダムス、ジョン・ケイヴ、ヘレン・ホウ-サンディ、ディオン・ハルス、モー・ジェンガ、ポール・マイオラナによる貢献
175 | 176 |バージョン1.0 2015年3月
177 | 178 |