WordPress セキュリティ

テスト前に WordPress を確認してください

VICE は、フォーカスされたプローブを実行する前に、WordPress ページ、ヘッダー、およびパブリック アセット マーカーの検証済みドメインをチェックします。これにより、結果は、推測されたテクノロジー ラベルではなく、観察された CMS の動作に関連付けられます。

WordPress が確認できない場合、監査ではセキュリティ スコアや脆弱性が特定されるのではなく、対象範囲の制限が報告されます。

公的個人情報の暴露を検討する

WordPress は、作成者のリダイレクトとパブリック REST ユーザー エンドポイントを通じてアカウント名を明らかにすることができます。 VICE は観察された動作を記録するので、サイトの意図した公開モデルと比較できます。

• ログイン名または表示名を公開するアーカイブ リダイレクトを作成します。
• REST ユーザーエンドポイントからのパブリック応答。
• 機密応答コンテンツを保存せずにテストされたパスを識別する証拠マーカー。

XML-RPC、ログイン、および cron を検査する

到達可能性だけでは悪用を証明することはできません。検出された各問題は、観察されたより強い動作、その信頼性、および推奨される制御を説明する必要があります。

• パスワード試行の効率を高めることができる到達可能な XML-RPC 動作。
• デフォルトの WordPress ログイン パスとそのパブリック動作。
• WordPress cron エンドポイントへのパブリック HTTP アクセス。

重点的な監査を開始する

検証済みのドメイン ワークスペースで WordPress を開き、スキャンを開始します。実行は、すべての管理対象監査と同じステータスと履歴とともに中央監査リストに表示されます。

対処可能な問題がドメインで検出された問題ビューに追加されます。 WordPress は、完全なカスタマイズされたセキュリティ監査内でも引き続き利用できます。

コンテキスト内で露出を読み取る

公開された著者名は出版サイトでは意図的に使用されている可能性がありますが、他の場所で再利用されるログイン識別子はより大きなリスクを生み出します。アカウント モデル、認証制御、および運用要件に対する証拠を確認します。

失敗したリクエストまたは到達不能なサイトは、カバレッジの制限です。これは、WordPress で検出された重大な問題ではありません。

修正して再テストする

検出された問題を解決済みとしてマークする前に、同じワークスペースから焦点を絞った WordPress 監査を再実行し、同等のカバレッジを比較します。

• サイトで必要がない場合は、パブリック ユーザーの列挙を制限します。
• 未使用の場合は XML-RPC を無効にするか、強力な認証とレート制限で必要なメソッドを保護します。
• レート制限、強力な資格情報、および利用可能な場合は多要素認証を使用してログイン フローを保護します。
• パブリック HTTP トリガーが不要な場合は、WordPress cron 用のサーバー スケジューラを優先します。