セキュリティ

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

概要

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

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

要旨

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

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

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

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

WordPress の概要

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

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 セキュリティチーム

WordPress セキュリティチームは、リード開発者やセキュリティ研究者を含む約50人の専門家の集団で構成されています。約半数は Automattic (Web 上で最も速く、最大規模の WordPress ホスティングプラットフォームである WordPress.com の運営企業) の従業員であり、多くは Web セキュリティの分野で働いています。チームは、著名で信頼できるセキュリティ研究者やホスティング会社s3への相談も行っています。

WordPress セキュリティチームは、WordPress 3.9.24で WordPress 同梱の XML-RPC API で使用されている PHP XML パーサーの脆弱性を解決するなど、共通の依存関係にある問題に対処するために他のセキュリティチームと連携することがよくあります。この脆弱性は、WordPress と Drupal の両方のセキュリティチームが共同で取り組んだ結果として解決しました。

WordPress のセキュリティリスク、プロセス、およびその歴史

WordPress セキュリティチームは、潜在的な脆弱性があればすぐにセキュリティチームに警告するという「責任ある開示」を重要視しています。潜在的なセキュリティ脆弱性は、WordPress HackerOne5 を通じてセキュリティチームに通知することができます。セキュリティチームは、プライベートな Slack チャンネルを介してコミュニケーションをとり、壁のないプライベートな Trac でバグやセキュリティ問題の追跡、テスト、修正を行います。

各セキュリティレポートは受信時に確認され、チームは脆弱性を検証し、その深刻度を判断します。脆弱性が確認された場合、セキュリティチームは問題を修正するパッチを計画します。パッチは次回の WordPress ソフトウェアリリースに含めるか、問題の深刻度に応じては即時のセキュリティリリースとしてプッシュします。

直ちにセキュリティリリースを公開するために、セキュリティチームは WordPress.org のニュースサイト6にセキュリティ勧告を公開し、リリースを発表し、変更を詳細に説明しています。今後も責任ある報告を推奨し助けるため、セキュリティ勧告に脆弱性の責任ある開示についてのクレジットを掲載しています。

新規リリースが利用可能になると、WordPress ソフトウェアの管理者にはサイトのダッシュボードにアップグレードの通知が表示されます。手動でアップグレードした後、ユーザーは変更点の詳細を記載した WordPress についての画面にリダイレクトされます。管理者が自動バックグラウンドアップデートを有効にしている場合は、アップグレードが完了した後にメールが届きます。

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

WordPress はバージョン3.7以降から、3.7.1や3.7.2 などのすべてのマイナーリリース7に対して自動バックグラウンドアップデートを導入しました。WordPress セキュリティチームは、サイトオーナーがサイト側で何もしなくても WordPress の自動セキュリティ強化を識別、修正、プッシュアウトすることができ、セキュリティアップデートは自動的にインストールされます。

WordPress の現在の安定版リリースに対してセキュリティアップデートがプッシュされると、コアチームはバックグラウンドアップデートが可能なすべてのリリース (WordPress 3.7以降) に対してもセキュリティアップデートをプッシュするので、これらの古いバージョンであっても最新のバージョンの WordPress はセキュリティ強化を受けることになります。

サイト所有者はそれぞれ、設定ファイルを簡単に変更することで自動バックグラウンド更新を削除できますが、この機能を維持することと WordPress の最新の安定版を実行することはコアチームによって強く推奨されています。

2013 OWASP Top 10

Open Web Application Security Project (OWASP) は、Web アプリケーションセキュリティに特化したオンライン コミュニティです。 OWASP トップ10リスト8は、幅広い組織にとって最も深刻なアプリケーション セキュリティ リスクを特定することに重点を置いています。 トップ10の項目は、悪用可能性、検出可能性、および推定される影響度に関するコンセンサス予測を組み合わせて選択され、優先順位が付けられます。

以下のセクションでは、これらの潜在的なリスクに対して WordPress がコアソフトウェアやサードパーティのプラグイン・テーマを強化するために使用している API、リソース、ポリシーについて説明します。

A1 – インジェクション

WordPress には、不正なコードが注入されないため一連の関数とAPIが用意されており、開発者によるデータの検証やサニタイズに役立ちます。これらのAPIを使用して HTML、URL、HTTPヘッダー、データベースやファイルシステムとやり取りする際の入出力データを保護、検証、サニタイズする方法については、ベストプラクティスとドキュメントが用意されています9。管理者は、フィルターを使うことでアップロードできるファイルの種類をさらに制限できます。

A2 – 不完全な認証とセッション管理

WordPress コアのソフトウェアでは、ユーザーアカウントの管理や認証、ユーザー ID、名前、パスワードなどの詳細は、認証 Cooke と同様にサーバー側で管理されています。パスワードは、標準的な Salt 化やストレッチ技術を用いてデータベースで保護されています。WordPress 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 のセキュリティ設定操作の大部分は、権限を与えられた一人の管理者に限定されています。WordPress のデフォルト設定はコアチームで継続的に評価されており、WordPress コアチームは WordPress サイトを実行するためのサーバー設定のセキュリティを強化するためのドキュメントやベストプラクティス11を提供しています。

A6 - 機密データの暴露

WordPress ユーザーアカウントのパスワードは、Portable PHP Password Hashing Framework12に基づいてソルト化およびハッシュ化されます。WordPress の権限システムは、登録ユーザーの PII、コメント投稿者の電子メール アドレス、非公開コンテンツといったプライベートな情報へのアクセスを制御するために使用されます。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 Twenty-Four」) は、セキュリティ上の理由からテーマ開発者チームに加えてコア開発チームと両方によってしっかりとレビューされ、テストされています。

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

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

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

WordPress.org のリポジトリにプラグインやテーマが登録されていても、セキュリティ上の脆弱性がないことを保証するものではありません。プラグイン作者のためにリポジトリに登録する前に参照するガイドラインが提供されており17、また、WordPress テーマの開発方法に関する様々なドキュメント18が WordPress.org サイトで提供されています。

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

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

テーマレビューチーム

テーマレビューチームは WordPress コミュニティから認められ、キーとなるメンバーによってリードされている、公式の WordPress テーマディレクトリ掲載のために申請されたテーマをレビュー及び承認をするボランティアのグループです。テーマレビューチームは、公式テーマレビューガイドライン 19、テーマユニットテストデータ 20、Theme Check プラグイン 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月


脚注