WordPressの公開機能を制限する｜不要な攻撃経路を減らす

当ページは検証・整備中のドラフトです。
内容は実環境での検証や追加調査により変更される予定です。
参照：ページ公開・更新ポリシー

WordPressが外部へ公開している機能を確認する

WordPressは記事や固定ページだけでなく、コメント、API、フィードなど複数の機能や情報を外部へ公開している。

これらは正当な用途があって実装されている機能であり、デフォルトの状態で利用しているからといって、直ちに大きな問題につながるものではない。

一方、攻撃者やBotから見れば、公開機能は情報収集やスパム送信、攻撃を成功させるための経路として利用できる。自分のサイトで使っていない機能まで公開しておく必要はないため、まず用途と悪用方法を把握する。

公開機能・情報正当な使われ方悪用例不要な場合
コメント読者から意見や質問を受け付けるスパム、不正URLの投稿、大量投稿停止を検討
問い合わせフォームWebから問い合わせを受け付けるスパム、Botによる大量送信設置しない・削除
XML-RPC外部アプリやサービスとの連携ログイン試行、Pingbackの悪用利用状況を確認して制限
REST APIWordPressや外部サービスとのデータ連携公開情報の収集、ユーザー列挙一律停止せず公開範囲を確認
RSS・フィードRSSリーダー、更新情報の配信記事の自動収集・転載不要なら停止・制限を検討
ユーザー情報投稿者情報の表示ユーザー列挙、ログイン試行への利用公開範囲を確認
メディア・添付ファイル画像やPDFなどの公開意図しない参照、収集、直リンク公開範囲を確認

公開されている機能と情報を個別に確認する

コメント

WordPressのコメントは、記事に対する意見や質問を読者から受け付ける機能である。一方、誰でも投稿できる状態にすると、Botによるコメントスパムの対象にもなる。

コメントを使わないサイトなら受付を停止し、利用する場合はスパム対策まで含めて提供方法を決める。

詳細：WordPressのコメント機能を設計する

問い合わせフォーム

問い合わせフォームは、必要な項目を指定して一定の形式で連絡を受け付けられる反面、Botによるスパム送信にも利用される。

問い合わせをメールや電話など別の方法で受け付けるなら、フォームを設置しない選択もできる。利用する場合は、Bot対策やスパム判定まで含めて受付方法を設計したい。

詳細：WordPressの問い合わせフォームを設計する

XML-RPC

XML-RPCは、外部のアプリケーションやサービスからWordPressと通信するための仕組みで、WordPressではxmlrpc.phpがその窓口となる。

正当な外部連携に利用できる一方、認証試行やPingback機能の悪用にも使われてきた。

現在利用している機能やサービスがXML-RPCに依存していないか確認し、用途がなければ制限を検討する。

REST API

WordPress REST APIは、WordPressの情報を取得したり、外部のアプリケーションと連携したりするための仕組みである。

WordPress本体やプラグインなども利用するため、REST APIそのものを不要な機能とみなして一律に停止するのは適切ではない。

一方、外部から記事やユーザーなどの情報を機械的に取得する経路にもなる。REST APIを使えるかどうかだけでなく、ログインしていない第三者がどの情報まで取得できるのかを確認したい。

不要な情報が公開されている場合は、必要な機能への影響を確認したうえで、対象となる情報やエンドポイントの制限を検討する。こうした制限はWordPressの標準設定だけでは行えず、プラグインやコードなどによる対応が必要になる場合もある。

RSS・フィード

RSSフィードは、記事の更新情報をRSSリーダーや外部サービスへ配信する仕組みである。

機械的に情報を取得できることが本来の利点だが、同じ性質を利用して記事を継続的に収集し、コピーサイトなどへ転載することもできる。

ただし、RSSを停止しても通常のWebページからスクレイピングできるため、コピー対策そのものにはならない。RSSを利用していない場合は、不要な公開経路を残さないという観点から停止や配信範囲の制限を検討する。

ユーザー情報

WordPressでは、REST API、投稿者ページ、投稿記事など複数の経路からユーザーに関する情報を取得できることがある。

こうした情報から登録ユーザーを探し出す行為をユーザー列挙という。

ユーザー名などを特定されれば、その情報を固定してパスワードを変えながらログインを試すことができる。表示名を変更していても、別の公開経路からユーザー情報を取得される可能性があるため、サイト全体として何を公開しているかを確認する。

メディア・添付ファイル

WordPressへアップロードした画像やPDFなどは、Web上から配信することを前提としたファイルである。

記事から画像を削除しても、メディアライブラリやサーバー上にファイル自体が残っていれば、URLから直接参照できる。「記事から消したので、もう見られることはない」と考えていた画像や資料が、引き続き外部から閲覧できるという事故も起こり得る。

そのため、WordPressのメディア領域を非公開のファイル保管場所として扱わない。公開を取りやめるファイルは、記事からリンクを削除するだけでなく、ファイル自体を残す必要があるかまで確認する。

また、公開された画像などを第三者のWebサイトから直接参照されることもある。このような直リンクでは、第三者サイトが表示されるたびに自分のサーバーからファイルが配信されるため、自サイトの閲覧にはつながらないまま転送量やサーバー負荷だけが増える可能性がある。

必要な公開機能だけを残す

WordPressの公開機能は、それぞれ正当な理由があって実装されている。そのため、デフォルトの状態で公開されていること自体を問題とする必要はない。

ただし、攻撃者は公開された機能や情報を調査し、スパム送信、ユーザー列挙、ログイン試行などに利用している。

公開機能・情報を確認
        ↓
サイトで使用しているか
    ┌───┴───┐
   使用      不使用
    ↓         ↓
用途と対策   停止・制限を検討
を確認

必要な機能には用途に応じた対策を行い、使っていない機能は停止や制限を検討する。

機能を一つ閉じただけでWordPressへの攻撃を防げるわけではない。しかし、攻撃に利用できる経路を必要なものだけに絞れば、攻撃を受ける可能性や頻度を減らすことにつながる。

まとめ

WordPressには、コメント、問い合わせフォーム、XML-RPC、REST API、RSS、ユーザー情報、メディアなど、Webサイトを運用するためのさまざまな公開機能が用意されている。

これらは本来の用途に沿って使う限り有用であり、デフォルトのまま利用していることが直ちに大きな問題になるわけではない。一方で、攻撃者やBotが公開機能を悪用し、攻撃を成功させやすくしている側面もある。

すべてを閉じるのではなく、自分のサイトで必要な機能を把握する。使っていない公開機能を閉じ、必要なものだけを残すことで、攻撃に利用できる経路を減らしていくのがこのユニットの目的である。