セキュリティ問題の修正
プラグインにセキュリティ問題の報告を受け取ると、恐ろしいことがあります。まず、パニックにならないでください。誰にでも間違いはあります。最も重要なのは、安全かつ迅速に修正することです。
- 1. 報告内容を理解していることを確認してください。意味がわからない場合は、詳細を尋ねてください。サードパーティの報告者も通常、何が問題なのかを説明し、適切な修正方法を調査するための指示をするために時間をかけてくれることが多いです。
- 2. 変更はできるだけ小さく保ってください。これにより、後でレビューがはるかに簡単になります。
- 3. プラグインをテストしてください。セキュリティ修正が他の何かを壊さないことを確認してください。アップグレードが奇妙なエラーを引き起こさないことを確認してください。
WP_DEBUG
をオンにして、エラーをログに記録してください。 - 4. 変更ログに問題を文書化してください。何が起こったかの詳細を含める必要はありませんが、セキュリティ問題が解決されたことは文書化してください。
- 5. READMEに報告者のクレジットを記載してください。これは単に親切であり、後で無料で助けてくれる人々をより引き付けます。
- 6. バージョン番号を上げてください。私たちはSemVerを推奨していますので、プラグインのバージョン3.9のセキュリティリリースはバージョンを3.9.1に変更します。
自動プラグインセキュリティ更新
WordPress 3.7以降、プラグインの重大な脆弱性を修正するために自動セキュリティ更新をプッシュする機能が追加されました。多くのサイトは、フィルターを通じて直接オプトインするか、利用可能な多くのリモート管理サービスのいずれかを使用して、プラグインの自動更新機能を利用しています。
極端な状況では、プラグインレビューチームとWordPressセキュリティチームが、プラグインの問題が十分に重大であると判断した場合、すべてのユーザーのために更新する必要があります。これは非常にまれであり、競合の可能性が高いためです。
プラグインを自動更新のために承認し、WordPressユーザーに展開するプロセスは非常に手動です。セキュリティチームは、リリース内のすべてのコード変更をレビューし、問題と修正を確認し、プラグインが更新をトリガーするのに安全であることを確認します。自動更新を展開するには、APIコードの変更と展開が必要です。これはコアセキュリティリリースのための同じ基準とプロセスです。
基準
セキュリティプッシュのために考慮する現在の基準は、シンプルなリストです:
- 1. セキュリティチームは問題を認識していますか?
- 2. 問題の深刻度はどのくらいですか? WordPressインストールのセキュリティやインターネット全体にどのような影響を与えますか?
- 3. 問題の修正は自己完結型ですか、それとも重要な余分な冗長コードを追加しますか?
- 4. プラグインの複数のブランチが影響を受けている場合、各ブランチのリリースは準備されていますか?
- 5. 更新は自動的に安全にインストールできますか?
これらの要件は、誰でも各ボックスにチェックを入れられるように定義されています。
最初の基準 — セキュリティチームに問題を認識させること — は重要です。これは厳密に管理されたプロセスであるため、WordPressセキュリティチームにはできるだけ早く通知する必要があります。私たちに知らせるのは、[email protected]
に詳細をメールするだけで簡単です。
プラグインとセキュリティチームは、プラグインの著者(異なる場合は報告者)と協力して、脆弱性とその正確な露出を調査し、提案された修正を確認し、どのバージョンがリリースされるか、いつリリースされるかを決定します。
FAQ
プラグインの自動更新をリクエストするにはどうすればよいですか?
プラグインのユーザーベースが十分に大きいと感じる場合や、問題が非常に重要である場合は、コードをプッシュする前に[email protected]
にメールしてください。変更のパッチをレビュー用にメールに含め、なぜこれを自動化すべきだと感じるのかを説明してください。
自動更新のためにセキュリティ関連以外の変更を含めることはできますか?
例外はほとんどありませんが、いいえ。セキュリティプッシュはセキュリティ関連のもののみであるべきです。私たちは、セキュリティ問題のみを修正し、最小限のコード変更で、無関係な変更を含まないプラグインリリースを好み(多くの場合、要求します)。
これにより、誰もが変更を迅速にレビューでき、はるかに自信を持てるようになります。また、ユーザー側の混乱が最小限に抑えられます。
なぜプラグインAは自動更新されたのに、プラグインBはされなかったのですか?
これはWordPress.orgからの偏見ではなく、私たちが使用している手動プロセスの名残です。問題が通知されれば、私たちはそれに対処します。数日後に問題が発覚した場合、修正を展開する機会は通常過ぎてしまい、効果的ではなくなります。
自動更新を無効にするにはどうすればよいですか?
この機能を無効にするためのいくつかのオプションがあります。コアの自動更新を無効にするための記事がここに適用されます。すべての自動更新機能を無効にするものは、プラグインの更新を防ぎます。すべてのプラグインまたは単一のプラグインの更新を無効にしたい場合は、単一のフィルター呼び出しでそれを行うことができます。
コードを修正できない(または修正したくない)場合はどうすればよいですか?
修正する必要はありません。プラグインは閉じたままとなり、2か月または3か月後に、プラグインページにはセキュリティ問題のために閉じられたと報告されます。修正をプッシュしたいがプラグインを閉じたままにしたい場合も、私たちはそれを行うことができます。メールに返信して私たちに話してください。
報告された問題だけを修正すればよいですか?
はいといいえ。報告された問題を修正する必要がありますが、完了したら、プラグイン全体が再レビューされ、他に問題が見つかった場合は、それらも修正する必要があります。最終的な目標は、再オープンされたプラグインが安全であることを確認することです。
ガイドラインの問題がある場合はどうすればよいですか?
これは、jQueryの独自のコピーを含めたり、文書化されていない外部サービス呼び出しを行ったりするなど、他のガイドラインを破っている場合に発生します。他の問題の深刻度によります。独自のjQueryだけの場合は、再オープンを許可し、そのペースで修正できる可能性が高いです。プラグインのすべてのインストールをログに記録している場合は、プラグインを再オープンする前にそれを修正する必要があります。