セキュリティ

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

概要

このドキュメントは、WordPress コアソフトウェアの開発とそれに関連するセキュリティプロセスの分析と説明だけでなく、ソフトウェアに直接組み込まれる固有のセキュリティの調査でもあります。コンテンツ管理システムや Web アプリケーションフレームワークとして WordPress を評価する立場にある意思決定者は、自分の分析と意思決定にこの文書を利用するべきであり、開発者は、この白書を参照してこのセキュリティコンポーネントとこのソフトウェアのベストプラクティスに習熟するべきです。

この文書に記載されている情報は、この白書公開時の最新安定版ソフトウェア、WordPress 4.1 の最新版のものですが、WordPress 開発チームは後方互換性に最大限の注意を払っているので、直近のこのソフトウェアのいくつかのバージョンでも関連するものと考えてください。特定のセキュリティ対策と変更は、コアソフトウェアの特定のリリースで追加されたものとして言及されます。可能な限りの安全性を確保するため、常に WordPress の最新安定版を利用するよう強くおすすめします。

要旨

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

WordPress は2003年のその始まりから継続して堅牢化され続けているので、このコアのソフトウェアは一般的なセキュリティーの脅威に対処したりそれを軽減したりできます。 このセキュリティの脅威には Open Web Application Security Project によって一般的なセキュリティの脆弱性として識別されているトップ10のものも含まれ、この文書でまた考察いたします。

WordPress のセキュリティチームは、WordPress のコアリーダーシップチームと共同で、また WordPress のグローバルコミュニティに支えられ、WordPress.org で配布され、インストールされるコアソフトウェアのセキュリティ問題を特定、解決すべく尽力しています。同様にまた、第三者のプラグインとテーマ作成者のためにセキュリティのベストプラクティスを推奨したり文書化したりしています。

サイトの開発者および管理者のみなさんは、コア API の正しい利用と一般的な脆弱性の源となってきているサーバーの設定には特別な注意を払うようにし、また同様に、WordPress にアクセスするためのパスワードに強力なものを利用するようにすべてのユーザーに対して確実を期すべきです。

WordPress の概要

WordPress は「フリー (無料かつ自由)」なオープンソースのコンテンツ管理システム (CMS) です。これは、世界で最も広く使用されている CMS ソフトウェアです。トップ1千万サイトのうち30%以上 1 のサイトを動かしており、CMS を使用しているすべてのサイトの60%の市場シェアを占めると推定されます。

WordPress is licensed under the General Public License (GPLv2 or later) which provides four core freedoms, and can be considered as the WordPress “bill of rights”:

  1. どんな目的に対してもプログラムを実行できる自由。
  2. プログラムの仕組みを調査し、望む動作をさせるよう変更する自由。
  3. 再頒布する自由。
  4. 変更を加えた独自のバージョンの複製を他の人に頒布する自由。

WordPress のコアリーダーシップチーム

WordPress のプロジェクトは実力主義で、コアリーダーシップチームによって運営され、その共同創始者でありリード開発者のマット·マレンウェッグに率いられています。このチームは、コア開発、WordPress.org、およびコミュニティへの主導権など、このプロジェクトのすべての側面を統制しています。

このコアリーダーシップチームは、マット·マレンウェッグ、5人のリード開発者、および1ダース以上の恒久的なコミットアクセスを持つコア開発者によって構成されています。これらの開発者は、技術的判断に関する最終的な権限を持っていて、アーキテクチャに関する議論と実装の取り組みをリードしています。

WordPress には寄与してくれるたくさんの開発者がいます。こうした開発者の中には以前の、もしくは現行のコミッターがいたり、あるいは将来的にコミッターとなる可能性の高い方もいたりします。こうした貢献開発者は信頼され、WordPress へのベテランの貢献者は仲間の間で大いに尊敬を得ています。WordPress にはまた、必要に応じたゲストコミッターがいます。コミットアクセスを許可された個人で、時には特定のコンポーネントのために一時的もしくは実験的な場合もあります。

こうしたコア開発者と寄与開発者が WordPress の開発を主にリードしています。各バージョンで数百人もの開発者が WordPress にコードを寄与してくれています。これらのコアコントリビューターは何らかの方法でコアのコードベースに寄与するボランティアです。

WordPress のリリースサイクル

WordPress のそれぞれのリリースサイクルは、一人もしくは複数の WordPress のコア開発者がリードします。一つのリリースサイクルは通常、最初の開発範囲選考ミーティングからそのバージョンのリリースまで、約4ヶ月です。

リリースサイクルは、以下のパターン 2 に従います。

  • フェーズ1: 計画とチームのリード役の確保。これは、Slack の #core チャットルームで行われます。リリースリード役は、WordPress の次のリリースのための機能について議論します。WordPress のコントリビューターもその議論に参加します。リリースリード役が各機能ごとにそのチームのリード役を特定します。
  • フェーズ2: 開発作業が開始されます。チームのリード役は、チームを組み立て、割り当てられた機能に取り組みます。開発を確実に前進させるため、チャットが定期的に開催されます。
  • フェーズ3: ベータ版。ベータ版がリリースされ、ベータテスターはバグ報告の開始を依頼されます。このフェーズ以降、新しい拡張や機能のリクエストのためのコミットは実施されません。サードパーティのプラグインとテーマの作者は、そのリリースでこれから変更される点に対して自分たちのコードをテストすることを促されます。
  • フェーズ4: リリース候補。この時点から、翻訳可能な文字列の変更は停止されます。作業の対象はリグレッション (訳注:修正済みのバグや不具合の再発箇所) とブロッカー (訳注:正式版としてのリリースを阻む重大な不具合) のみになります。
  • フェーズ5: 正式版のリリース。WordPress の正式版がリリースされ、更新のために WordPress の管理画面からそのアップデートが利用可能になります。

バージョン番号とセキュリティリリース

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

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

WordPress のマイナーバージョンは3番目の数字によって決まります。バージョン3.5.1はマイナーリリースで、3.4.2もまた同様にマイナーリリースです3 。マイナーリリースは、セキュリティ脆弱性の修正と重大なバグの対処のみに限定されます。WordPress の新しいバージョンがこのように頻繁にリリースされているので – 目標としてはメジャーリリースが4〜5ヶ月ごと、マイナーリリースは必要に応じて – 必要となるのはメジャーとマイナーリリースのみです。

バージョンの後方互換性

WordPress のプロジェクトは、後方互換性への強い信念を持っています。この信念はつまり、WordPress のコアソフトウェアがアップデートされてもテーマ、プラグイン、およびカスタムなコードが機能し続けるという意味であり、それによりまた、サイトのオーナーに自分たちの WordPress バージョンを最新の安全なリリースのバージョンに保つように促すことにもなります。

WordPress とセキュリティ

WordPress セキュリティチーム

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

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

WordPress Security Risks, Process, and History

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

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

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

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

Automatic Background Updates for Security Releases

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

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

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

2013 OWASP Top 10

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

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

A1 - Injection

There is a set of functions and APIs available in WordPress to assist developers in making sure unauthorized code cannot be injected, and help them validate and sanitize data. Best practices and documentation are available9 on how to use these APIs to protect, validate, or sanitize input and output data in HTML, URLs, HTTP headers, and when interacting with the database and filesystem. Administrators can also further restrict the types of file which can be uploaded via filters.

A2 - Broken Authentication and Session Management

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

A3 - Cross Site Scripting (XSS)

WordPress provides a range of functions which can help ensure that user-supplied data is safe10. Trusted users, that is administrators and editors on a single WordPress installation, and network administrators only in WordPress Multisite, can post unfiltered HTML or JavaScript as they need to, such as inside a post or page. Untrusted users and user-submitted content is filtered by default to remove dangerous entities, using the KSES library through the wp_kses function.

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

A4 - Insecure Direct Object Reference

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

A5 - Security Misconfiguration

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

A6 - Sensitive Data Exposure

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

A7 - Missing Function Level Access Control

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

A8 - Cross Site Request Forgery (CSRF)

WordPress uses cryptographic tokens, called nonces13, to validate intent of action requests from authorized users to protect against potential CSRF threats. WordPress provides an API for the generation of these tokens to create and verify unique and temporary tokens, and the token is limited to a specific user, a specific action, a specific object, and a specific time period, which can be added to forms and URLs as needed. Additionally, all nonces are invalidated upon logout.

A9 - Using Components with Known Vulnerabilities

The WordPress core team closely monitors the few included libraries and frameworks WordPress integrates with for core functionality. In the past the core team has made contributions to several third-party components to make them more secure, such as the update to fix a cross-site vulnerability in TinyMCE in WordPress 3.5.214.

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

A10 - Unvalidated Redirects and Forwards

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

さらなるセキュリティリスクと懸念

XXE (XML eXternal Entity) processing attacks

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

SSRF (サーバーサイドリクエストフォージェリー) 攻撃

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.

WordPress のテーマとプラグインのセキュリティ

デフォルトテーマ

WordPress requires a theme to be enabled to render content visible on the frontend. The default theme which ships with core WordPress (currently "Twenty Seventeen") has been vigorously reviewed and tested for security reasons by both the team of theme developers plus the core development team.

デフォルトテーマは、カスタムテーマ開発のための出発点として使うことができます。サイト開発者は、いくつかのカスマイズを含めながら機能と安全性のほとんどをこのデフォルトテーマに頼る子テーマを作成できます。必要でない場合、管理者はデフォルトテーマを簡単に削除できます。

WordPress.org テーマ/プラグインリポジトリ

There are approximately 50,000+ plugins and 5,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.

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.

各プラグインとテーマは、そのプラグインやテーマの所有者が継続的に開発し、その後の修正や機能開発をリポジトリにアップロードし、その変更の説明と一緒にそのプラグインやテーマをユーザーが利用できるようになっています。サイト管理者には、管理用ダッシュボードを介して更新する必要があるプラグインが通知されます。

WordPress セキュリティチームがプラグインの脆弱性を発見した場合、チームはそのプラグインの作成者に連絡し、そのプラグインの安全なバージョンのための修正とリリースに協力します。そのプラグインの作成者からの応答がない場合、またはその脆弱性が重大な場合には、そのプラグイン/テーマは公開ディレクトリから取り除かれ、場合によってはセキュリティチームによって直接修正、更新されます。

テーマレビューチーム

テーマレビューチームはボランティアのグループで、WordPress コミュニティから認められ、キーとなるメンバーによってリードされて、彼らにより公式の WordPress テーマディレクトリ掲載のために申請されたテーマをレビューされ、承認されます。テーマレビューチームは、公式テーマレビューガイドライン 19、テーマユニットテストデータ 20、テーマチェックプラグイン 21 のメンテナンスを行っています。また、テーマ開発のベストプラクティスに関する WordPress のテーマ開発者コミュニティの参加、教育に取り組もうとしています。このグループへの参加は WordPress 開発チームのコアコミッターたちによってモデレートされています。

WordPress のセキュリティにおけるホスティングプロバイダの役割

WordPress は多数のプラットフォームにインストールすることができます。WordPress のコアソフトウェアでは、このドキュメントでカバーされている安全なウェブアプリケーションの運営のため多くの対策を提供していますが、このソフトウェアをホストするオペレーティングシステムや基盤となるウェブサーバーの設定もまた WordPress を安全に保つために同じように重要です。

WordPress.com と WordPress のセキュリティに関するメモ

WordPress.com は WordPress の設置数として世界最大で、WordPress プロジェクトの共同創始者でもあるマット・マレンウェッグが設立した Automattic が所有、管理しています。WordPress.com は、WordPress コアのソフトウェア上で動作し、独自のセキュリティプロセス、リスク、およびソリューションを持っています 22 。この文書は、自分で運営するタイプ、WordPress.org からダウンロード可能で世界中のどのサーバーにもインストール可能なオープンソースの WordPress に関するセキュリティについてのものです。

付録

WordPress コア API

WordPress コアのアプリケーションプログラミングインターフェイス (API) は、いくつかの個別の API 23 で構成され、それぞれ関係する関数、利用目的、与えられている一連の機能をカバーしています。これらの API は共にプロジェクトのインターフェイスを形作っています。それによって、プラグインやテーマによる安全かつ確実な WordPress コア機能とのやり取り、変更、拡張が可能になっているのです。

WordPress API はそれぞれ、ベストプラクティスと WordPress コアソフトウェアを拡張するための標準化された方法を提供していますが、WordPress のセキュリティを強化し堅牢化することにもっとも関連するのが次の WordPress API です。

データベース API

WordPress 0.71 で実装されたデータベース API 24 は、データベースに格納されているデータに、名前付きの値としてアクセスするための正しい方法を提供します。

ファイルシステム API

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.

これは WP_Filesystem_Base クラスといくつかのサブクラスを通じて行なわれます。これらのクラスは、各ホストのサポート状況に応じてローカルファイルシステムに接続するためのさまざまな方法を実装しています。ローカルのファイルに書き込む必要があるテーマやプラグインは、一群の WP_Filesystem クラスを使って行います。

HTTP API

WordPress 2.7 28 で追加され、WordPress 2.8でさらに拡張された HTTP API 27 は、WordPress の HTTP リクエストを標準化しています。この API は、クッキー、gzip 圧縮符号化及び復号化、チャンクデコード (HTTP 1.1の場合)、およびその他の種々の HTTP プロトコル実装を処理します。この API は、リクエストを標準化し、送信する前に各メソッドをテストし、サーバー設定に基づいてリクエストを生成するために適切な方法を使用します。

権限と現在のユーザー API

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.

この白書コンテンツのライセンス

この文書内のテキスト (WordPress のロゴおよび商標を除く) は、CC0 1.0 Universal (CC0 1.0) Public Domain Dedication のもとにライセンスされています。利用者は許可を求める必要なく、商業目的であっても作品の複製・変更・配布・実行を行うことができます。

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

追加資料


執筆: サラ・ロッソ

バリー・エイブラハムソン、マイケル・アダムス、ジョン・ケイヴ、ヘレン・ホウ-サンディ、ディオン・ハルス、モー・ジェンガ、ポール・マイオラナによる貢献

バージョン1.0 2015年3月


脚注