セキュリティ

WordPress のセキュリティについて詳しく知りましょう。このドキュメントはPDF 形式でダウンロードすることもできます。

概要

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

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

要旨

WordPress は、非常に多数のウェブサイト、ウェブアプリケーション、ブログを動かすために使われている動的なオープンソースのコンテンツ管理システムです。現時点では、インターネット上のトップ1千万ウェブサイトのうち31%以上で利用されています。WordPress の使いやすさ、拡張性、および成熟した開発コミュニティによって WordPress は普及し、あらゆる規模のウェブサイトのための安全な選択肢となっています。

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

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

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

WordPress の概要

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

WordPress はコアとなる4つの自由を提供する一般公衆利用許諾契約書 (GPLv2 もしくはそれ以降)の下でライセンスされており、それはまた WordPress の「権利章典」と考えることができます:

  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 の管理画面からそのアップデートが利用可能になります。

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

WordPress のメジャーバージョンは最初の二つの数字によって決定されます。たとえば、3.5はメジャーリリースで、3.6、3.7、4.0もまた、メジャーリリースです。「WordPress 3」または「WordPress 4」は存在しません。各メジャーリリースはその番号付け、例えば「WordPress 3.9」と言及されます。

メジャーリリースでは、新しいユーザー向けの機能と開発者開発者向けの API を追加することがあります。ソフトウェアの世界では通常、「メジャー」バージョンというのは後方互換性なくすこともできることを意味しますが、WordPress は後方互換性を保つよう努めています。開発者にとっても同様ですが、ユーザーにとってもアップデートをより簡単な事にするため、後方互換性というのはこのプロジェクトにとってもっとも重要な理念の一つです。

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 のセキュリティリスク、プロセス、およびその歴史

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.

セキュリティリリース用の自動バックグラウンド更新

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 – インジェクション

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 – 不完全な認証とセッション管理

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 – クロスサイトスクリプティング (XSS)

WordPress は、ユーザーの入力したデータが安全であることを保証するのに役立つさまざまな機能を提供しています10。信頼できるユーザー (シングルインストールにおいては管理者と編集者、マルチサイトの場合は特権管理者のみ) は、必要に応じて投稿や固定ページ内などでフィルタリングされていない HTML や JavaScript を投稿できます。信頼されていないユーザーおよび彼らによって投稿されたコンテンツは、wp_kses 関数を通じた KSES ライブラリを利用して危険なエンティティが削除するためにデフォルトでフィルタリングされます。

一例として、WordPress のコアチームは WordPress 2.3のリリース前に、関数 the_search_query() が多くのテーマ作者によって誤利用されていて、関数の出力がエスケープなしで HTML 内で利用されていることに気づきました。わずかに後方互換性を損なう極めて稀なケースとして、WordPress 2.3ではこの関数の出力があらかじめエスケープされるように変更されました。

A4 – 安全ではないオブジェクトの直接参照

WordPress は、URL やフォームフィールド内で利用可能なユーザーアカウントやコンテツの一意の数値識別子など、直接的なオブジェクト参照を提供することがよくあります。これらの識別子は直接的なシステム情報を開示していますが、WordPress の豊富なアクセス権とアクセス制御システムにより、許可されていないリクエストは阻まれています。

A5 – セキュリティ設定のミス

WordPress のセキュリティ設定操作の大半は、権限のある管理者1人のみに制限されています。WordPress のデフォルト設定はコアチームのレベルで継続的に評価され、WordPress コアチームは WordPress サイトを実行するためのサーバー設定のセキュリティを強化するためのドキュメントやベストプラクティス11 を提供しています。

A6 - 機密データの暴露

WordPressユーザーアカウントのパスワードは、ポータブル PHP パスワードハッシングフレームワーク%s に基づいてソルト化およびハッシュ化されます。登録ユーザーの PII、コメント投稿者のメールアドレス、非公開コンテンツなどのプライベートな情報へのアクセスを制御するために、WordPress のパーミッションシステムが使われています。WordPress 3.7ではコアのソフトウェアにパスワード強度メーターが導入され、ユーザーがパスワードを設定するための追加情報と強度を増すためのヒントを提供しています。WordPress には、HTTPS を必須にするための設定オプションもあります。

A7 - 関数レベルアクセスのない場合の制御

WordPress は、操作が実行される前に、すべての関数レベルのアクセス要求に対する認証と権限が適切かどうかを確認します。適切な認証がない管理用 URL、メニュー、ページへアクセスまたは可視化は、権限のないユーザーからのアクセスを防具ため、認証システムと緊密に統合されています。

A8 – クロスサイトリクエストフォージェリ (CSRF)

WordPress は nonce13 と呼ばれる暗号化トークンを使用して、潜在的な CSRF 脅威からの保護のため、認証済みユーザーからの操作要求の意図を検証します。WordPress は、一意かつ一時的なトークンを生成して検証するために、これらのトークン作成用の API を提供します。また、トークンは特定のユーザー・操作・オブジェクト・期間に限定され、必要に応じてフォームや URL に追加できます。さらに、すべての nonce はログアウト時に無効化されます。

A9 – 既知の脆弱性を持つコンポーネントの使用

WordPress のコアチームは、コア機能のために WordPress に含まれているライブラリや統合されているフレームワークのいくつかを密接に監視しています。コアチームはこれまでも、WordPress 3.5.214 における TinyMCE でのクロスサイトの脆弱性を修正するための更新など、こうしたサードパーティ製コンポーネントをより安全にするための貢献をいくつか行っています。

コアチームは必要に応じて重要な外部コンポーネントをフォークしたり入れ替えたりします。例えば、3.5.2では、SWFUpload ライブラリが Plupload ライブラリと公式に入れ替えられ、短期的に SWFUpload を使い続けるプラグイン用に SWFUpload の安全なフォークバージョンがセキュリティチーム15 によって提供されました。

A10 – 未検証のリダイレクトと転送

WordPress の内部のアクセス制御や認証システムは、ユーザーを望まないサイトへ導いたり、自動リダイレクトしたりする試みから保護します。この機能は、API の wp_safe_redirect()16 を介してプラグイン開発者も利用可能です。

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

XXE (XML eXternal Entity) 処理攻撃

XML を処理する際、WordPress は外部エンティティおよびエンティティ拡張攻撃の両方を防ぐためにカスタム XML エンティティの読み込みを無効化します。WordPress は、プラグインの作成者に対してPHP のコア機能以外の追加セキュア XML 処理 API を提供していません。

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

WordPress によって発行された HTTP リクエストは、ループバックおよびプライベート IP アドレスへのアクセスを防止するためにフィルタリングされています。さらに、アクセスは特定の標準 HTTP ポートにのみに限定されています。

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

デフォルトテーマ

WordPress は、フロントエンド上でコンテンツをレンダリングして表示させるためのテーマを必要とします。WordPress コアに同梱されているデフォルトテーマ (現在は「Twenty Seventeen」) は、セキュリティ上の理由からテーマ開発者チームに加えてコア開発チームと両方によってしっかりとレビューされ、テストされています。

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

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

WordPress.org サイト上にはおよそ50,000個以上のプラグインと5,000個以上のテーマが掲載されています。これらのテーマとプラグインは承認されリポジトリに登録される前にボランティアにより手動でレビューされています。

WordPress.org のテーマ/プラグインリポジトリに登録されているテーマ/プラグインはセキュリティの脆弱性がないと保証されているわけではありません。プラグイン作者へはリポジトリへの登録のためのガイドライン17 が提供され、またテーマ開発についてのドキュメンテーション18 は WordPress.org 上で提供されています。

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

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

WordPress 2.6 26 で追加されたファイルシステム API 25 は、もともと WordPress 独自の自動更新機能のために作られました。ファイルシステム API は、さまざまな種類のホスト上でファイルシステムにローカルファイルを安全に読み取り・書き込みするために必要な機能を抽象化しています。

これは 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

権限と現在のユーザー API 29 は、要求されている任意のタスクまたは操作を実行するために現在のユーザーのアクセス権や権限を確認するのに役立つ関数の集合であり、ユーザーが許可されていない機能にアクセスしたり、実行したりすることに対する保護をさらに強化できます。

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

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

この資料を作成するにあたってインスピレーションを与えてくれた Drupal セキュリティ白書に感謝します。

追加資料


執筆: サラ・ロッソ

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

バージョン1.0 2015年3月


脚注