WordPress プラグインのコードのセキュリティは、非常に慎重に考慮されています。
WordPress セキュリティチームによってプラグインの脆弱性が確認されると、プラグイン作者に連絡し、修正方法と安全なバージョンのプラグインのリリースを指示します。プラグイン作者からの応答がない場合、または脆弱性が深刻な場合は、プラグイン/テーマは公開ディレクトリから引き抜かれ、場合によってはセキュリティチームによって直接修正・更新されます。
セキュリティ課題の修正
プラグインにセキュリティの課題があるという報告を受けると、恐ろしくなります。まず、慌てないでください。誰にでもミスはあります。最も重要なのは、安全かつ迅速に修正することです。
- 報告の内容をよく理解してください。意味がわからない場合は、詳細を尋ねてください。第三者の報告者であっても、通常は時間を割いて何が問題なのかを説明し、適切な修正方法を調べる場所を指示してくれます。
- 変更はできるだけ最小限にとどめましょう。そうすることで、後で見直すのがずっと簡単になります。
- プラグインをテストしましょう。セキュリティ修正が他の何かを壊していないことを確認してください。アップグレードによって変なエラーが発生しないことを確認してください。
WP_DEBUGをオンにしておき、エラーがあればログに記録してください。 - 変更ログに課題を記録しましょう。何が起きたかについて詳細を書く必要はありませんが、セキュリティの課題が解決されたことを記録してください。
- readme に報告者についてクレジットしてください。これは単なる善意であり、のちのち、人々が無償であなたを助けようという気にさせるものです。
- バージョン番号を上げましょう。私たちは SemVer (semantic software versioning、意味論的ソフトウェア・バージョニング) を推奨しているので、プラグインのバージョン3.9のセキュリティリリースはバージョンを3.9.1などに変更します。
プラグインの自動セキュリティ・アップデート
WordPress 3.7以降、プラグインの重要な脆弱性を修正するために、プラグインの自動セキュリティアップデートをプッシュする機能が追加されました。多くのサイトが、フィルターを通して直接オプトインするか、利用可能な WordPress のリモート管理サービスのいずれかを使用して、プラグインの自動アップデート機能を利用しています。
極端な状況では、プラグインレビューチームと WordPress セキュリティチームが、プラグインの課題が全ユーザーのためにアップデートしなければならないほど大きいと判断することがあります。これは競合の可能性が高いため、非常にまれなケースです。
プラグインを自動アップデートの対象として承認し、WordPress ユーザーに展開するプロセスは、ほとんど手作業で行われます。セキュリティチームは、リリースのすべてのコード変更をレビューし、課題と修正を確認し、プラグインがアップデートを起動しても安全であることを確認します。自動アップデートの展開には、API コードの修正と配置が必要です。これは、コア・セキュリティリリースの標準およびプロセスと同じです。
評価基準
セキュリティ・プッシュのために考慮する、現在の評価基準は単純なリストです:
- セキュリティチームは、その課題を認知していますか ?
- その課題は、どの程度深刻ですか ? WordPress や インターネット全体のセキュリティにどのような影響がありますか ?
- 課題の修正は自己完結型ですか、それともかなり多くの過剰なコードを追加しますか ?
- プラグインの複数のブランチが影響を受ける場合、ブランチごとのリリースは準備されていますか ?
- アップデートは 安全に 自動的にインストールできますか ?
これらの要件は、誰もがそれぞれのボックスにチェックを入れられるように定義されています。
最初の評価基準 — セキュリティ・チームに課題を認知させること — は、非常に重要です。厳重に管理されたプロセスであるため、WordPress のセキュリティチームにはできるだけ早く通知する必要があります。WordPress セキュリティチームへの通知は、plugins@wordpress.org までメールで詳細をお知らせいただくだけで、簡単に行うことができます。
プラグイン・チームとセキュリティ・チームは、プラグイン作者 (異なる場合は報告者) と協力して、脆弱性とその正確な露出度を調査し、提案された修正を検証し、どのバージョンをいつリリースするかを決定します。
FAQ
プラグインの自動アップデートをリクエストするには ?
あなたのプラグインに十分なユーザーベースがあるか、課題が非常に重要であると感じる場合は、コードをプッシュする 前に plugin@wordpress.org にメールを送ってください。メールにはレビュー用の変更パッチを添付し、なぜ自動化する必要があるのかを説明してください。
自動アップデートの対象に、セキュリティ関連以外の変更を含めることは可能ですか ?
一部の例外を除いては、そうではありません。セキュリティ・プッシュはセキュリティに「だけ」関連すべきです。私たちは、セキュリティの課題「だけ」を修正し、最小限のコード変更で、関連性のない変更を含まないプラグインのリリースを好みます (そして、多くの場合、それを要求します)。
こうすることで、誰もが変更点をすばやく確認し、はるかに自信を持つことができます。また、ユーザー側の混乱も最小限に抑えられます。
プラグイン A には自動アップデートが適用され、プラグイン B には適用されないのはなぜですか ?
WordPress.org のバイアスではなく、これまでの手動プロセスに戻っただけです。もし私たちが課題に対して警告を受けたら、それに応えようと努力します。数日後に問題が発覚した場合、通常、修正プログラムを展開する機会は過ぎており、自動アップデートを実施してもそれほど効果的ではありません。
自動アップデートを無効にするには ?
この機能を無効にするにはいくつかのオプションがあります。コアの自動アップデートを無効にするの記事がこれに当てはまります。すべての自動更新機能を無効にすると、プラグインの更新ができなくなります。プラグインの更新だけを無効にしたい場合は、すべてのプラグインであれ、単一のプラグインであれ、1回のフィルター呼び出しで可能です。
自分のコードを修正できない (あるいは修正したくない) 場合は ?
その必要はありません。あなたのプラグインはクローズされたままとなり、2、3ヵ月後にプラグインのページに、セキュリティの課題でクローズされたことが報告されます。プラグインをクローズしたまま修正をプッシュしたい場合、私たちはそれも可能です。メールに返信して、私たちにご相談ください。
報告された課題だけを修正すればいいですか ?
Yes でもあり No でもあります。報告された課題は、修正しなければなりません が、それが終わるとプラグインが再レビューされ、さらに課題が見つかった場合は、それらも修正する必要があります。最終的な目標は、再開されたプラグインが安全であることを確認することです。
ガイドラインに課題がある場合は ?
これは、jQuery の独自のコピーを入れたり、ドキュメント化されていない外部サービスを呼び出したりするなど、他のガイドラインを破っている場合に発生します。他の課題の重大性に拠ります。あなた自身の jQuery だけであれば、私たちはおそらくその課題を再開させ、あなた自身のペースで修正することを許可するでしょう。プラグインのすべてのインストールを記録している場合は、プラグインを再開する前に修正する必要があります。