WordPressを正しく守るセキュリティ
見出し
前ページでは、WordPressのセキュリティ対策についてその多くが実際は推奨されていない「隠すセキュリティ」であることに触れてきた。
ではどうすれば正しくWordPressを守れるか、が本ページのテーマである。
そして、4,500サイト以上を復旧した経験から、改ざん被害をもたらす攻撃のパターン別に防御を考えてみたい。
改ざん被害をもたらす攻撃のパターン
主な経路としては3つに大別できる。
1.認証突破
2.コア・プラグインの脆弱性
3.独自テーマの脆弱性
認証突破させないために
2025年、足元で最も多い被害経路が認証突破によるものである。
要するに、パスワード強度が低いなどの理由でダッシュボード内に不正に侵入されてしまうパターンである。
長らく脆弱性由来の被害が多かったのに、この数年急に認証突破パターンが増えているわけだが、高性能なGPUが一般でも手に入りやすくなったこと、また仮想通貨のマイニング等で使用されていたGPUが、マイニングが難しくなったことで用途転換されている等が理由として考えられる。
防御するためにできることはいくつかある。
パスワード強度を上げる
15桁以上の複雑なパスワードを採用する、というのがまず最初であり最も有効な手段となる。
ログインURLを変えなきゃいけないのは、そもそも突破されかねないレベルでパスワード強度が低いからである。
これがしっかりしていればそんな小細工はしなくても問題ない。
なお、パスワードの定期変更などは必要ない。
パスワード設定時に必要な文字数や、記号を入れるとか大文字小文字数字を入れるといった組み合わせのルールなどの条件をパスワードポリシーと呼ぶ。
これをどう取り決めるかについては、ちゃんとNISTが指針を出しており、NIST SP 800-63というデジタルIDのガイドライン文書に記されている。
2025年7月にRevision4(要するに第4版)が発表されているので、これを元にするとよい。
3.1.1.2.にパスワードについての記述があるが、要約するとこうである。
1.パスワード長は最低15文字、多要素認証（MFA）との組み合わせであれば最低8文字。
2.大文字や小文字、記号などを組み合わせる複雑性要件は廃止された。この要件を加えると、password から Password1! のように容易に予測できる変更を行う傾向があるためで、複雑でなくても良い、という意味ではない。
3.パスワードの定期的な変更は不要、変更は漏洩ないし侵害された場合だけで良い。
4.ブロックリストは作れ。2.で複雑性要件はなくなったが、簡単で良いというわけではない。ブロックリストには予測可能な一般的なパスワードや、辞書に含まれている単語、過去に漏洩ないし侵害されたパスワードを含む必要がある、とされており、その前提があっての2.や1.である。
xmlrpc.phpには気をつける
不正にWordPressにログインしようとする場合、実際にログインに至るまでに攻撃者は相当回数のログイン試行を行っている。
「1分間に5回失敗したら10分ログイン試行できないことにしてるぜ！だからうちのサイトは大丈夫だぜ！」という人は気を付けて欲しい。
それは通常ログイン画面からのログイン試行の話で、しかも今はブロックされないよう時間を空けて試行するのが普通なのだ。1分おき、場合によって10分おきなどの試行も見られるが、パスワード強度が高ければまあ問題ない。
問題は、ログイン画面からではないログイン試行、ブルートフォースアタックである。
これはxmlrpc.phpから行われるもので、ログイン画面でログイン試行回数制限をかけていてもこっちはノーガードというケースが多い。
xmlrpc.phpは、外部のアプリやエディターとの連携などで用いられるいわば「遠隔操作するための機能」だと思ってもらえばよいだろう。
WordPress公式でも現在はREST APIが推奨されているが、XML-RPCという古いAPIもまだ利用できる仕組みになっており、記事の投稿など可能だが当然認証が必要になる。
つまりアカウント情報が正しいかどうかを、xmlrpc.phpにPOSTすることによって確かめることができるわけだ。
さて、 XML-RPCには標準で system.multicall というメソッドがあり、これによって複数のXML-RPCメソッドを1リクエストでまとめて投げることが可能になる。
簡単に言おう。
数十から数百といったパスワードを、1回のリクエストで試すことが可能、ということだ。
ログイン画面では5回失敗したら、つまり5つのパスワードを試したらブロックされるかもしれない。
しかし、xmlrpc.phpへのPOSTなら、同じ5回のリクエストで数百から千を超えるパスワードを試すことができるわけだ。
圧倒的にこちらの方が高速に大量のパスワードを試すことが出来てしまう。
基本的にこれが最も一般的な侵害のケースであると言って良い。
パスワード強度を上げれば問題ないとはいうものの、自分以外のユーザーのパスワード強度に不安がある、あるいはパスワードポリシーを明確化する前から大量のユーザーがいてパスワード強度が不明、などの場合、xmlrpc.phpへのアクセスを遮断したほうが安心だろう。
またパスワード強度が高いとしても、サーバーへの負荷がかかるためこうした視点からもxmlrpc.phpへのアクセス制限はしておいて損はない。
パスワードの使い回しをしない
メールアドレスとパスワードの組み合わせは世の中に大量に漏洩しており、リスト化され、販売されている。
たとえばあなたが会社のメールアドレスとパスワードで何らかのwebサービスに登録していたとしよう。
これが漏洩したとする。
もし同じメールアドレスを記載しているwebサイトを見つけたら、私が攻撃者ならリストにあるパスワードをログイン画面で試してみるかもしれない。
こうしたパスワードの使い回しによる被害は非常に多く起きており、必ずユニークなパスワードを各所に使う必要がある。
連携webサービスのアカウントも同様の管理を行う
WordPressでは、WordPress.comアカウントとの連携で機能を利用できるプラグインなどもある。
例えばJetpackプラグインではWordPress.com側から管理サイトを複数まとめて管理することもできる。
問題はWordPress.comのアカウント情報が何らかの事情で漏洩したり、あるいはパスワードの使い回しなどで侵害されてしまうケースである。
実際こうした事例は筆者自身も取り扱った経験があり、Jetpackの管理機能からバックドアをプラグインの形で管理サイトすべてにインストールされるというものだった。
連携webサービスは利便性の高いものも多いが、WordPress本体だけではなくこうした連携サービスのアカウントも同様の基準でパスワード強度を高めておく必要がある。
コア・プラグインの脆弱性
WordPressコア、プラグインの脆弱性も引き続き注意が必要な部分である。
重大な脆弱性の発生は以前より減っているが、年に何度かメジャーなプラグインで重大な脆弱性が見つかっており、これがたまたま使用プラグインだとその一発でやられる、ということになる。
悪用が比較的容易な場合、おおよそ数日以内に復旧案件として筆者の会社に持ち込まれることが多い。
つまり可能な限り早いアップデート、出来れば一両日中のアップデートが望まれるわけで、毎週定期的にアップデート、といったスタイルだと被害に遭うリスクがある。
とはいえ毎日ログインしてアップデートするのはだるい、忙しいしそんなに面倒見れない、という方も多いだろう。
そこで、対策として2点挙げておく。
自動アップデート、ないし定期的かつ緊急のアップデートが可能な体制構築である。
自動アップデートを適用する
プラグインは自動アップデートが可能であり、これを適用することだ。
そうすれば最短でアップデートが可能である。
WordPressにはWP-Cronという、自動的に動作する機能がある。
この中にwp_update_pluginsという動作があり、プラグインのアップデートの有無をチェックするのだが、これはWP-Cron が動いたタイミングで「前回から12時間以上たっていれば実行」される。
つまり原則として12時間ごとに動作するのだが、WP-Cronはページへのアクセスによって動作するので、アクセス数がほとんどないサイトなどでは厳密に12時間にならない。
とはいえ、意識せずとも自動的にアップデートを可能な限り早いタイミングで実行するためもっとも望ましい方法である。
とはいえ、自動アップデートを適用しないWebサイトが多いのも事実である。
定期的なアップデート、そして緊急のアップデートが可能な体制構築
セキュリティとは無関係な通常のバグ修正、機能追加などのアップデートは定期的なアップデートで十分だが、先述した通り問題になるのは緊急のアップデートである。
つまり、急ぎ修正すべき脆弱性が見つかった場合に、速やかにセキュリティパッチを当てる必要があるということだ。
筆者らは複数の海外情報源を元に、毎日脆弱性情報を取得し緊急のアップデートを実施する保守サービスを行っているが、これはサイトオーナー、また制作会社でも可能である。
この際気を付けなければならないのは、CVEだけ見ていればよい、というわけではないことだ。
プラグインの場合、開発者が中小ベンダーや個人といったケースも珍しくない。
このためパッチ優先でCVEの申請が後回しになったり、まったくされないといったこともある。
パッチは公開されているのにCVEがついても数か月後といったことも珍しくないが、パッチ公開時点でPoCもネット上に流れている例も多く、CVEを待っていると確実に手遅れになる。
よって、複数の情報源から最新の情報を取得し、速やかに対応していく必要がある。
日本語情報を待つ、というのはもう論外だと言って構わない。
もしあくまで手動アップデートということであれば、こういう体制構築がなされれば問題なく運用できるだろう。
それも難しい、でも手動アップデート、という場合は保守サービスの導入を検討するべきである。
自動アップデートを適用しないWebサイトが多い理由
さて、被害の多くのケースでサイトオーナーはプラグインのアップデートが自動か手動かを把握していない。
そして、たいていの場合手動を強制しているのはWeb制作者である。
制作者の観点で言うと、アップデートによってデザインが崩れたり、あるいは機能的な部分で不具合を起こしたりといったことを避けるためであり、気付いたら数日エラー画面になっていた、というような事態を避けるためでもある。
またこのパターンのほぼすべてで、アップデートによるエラーが発生した場合の対応について取り決めがなされていない。
これについては悪質と言い切ってよいと思うが、アップデートの通知自体を切っているケースもある。
つまりアップデートすべきコアやプラグインの新しいバージョンがあるかどうか、把握できないようになっている。
車で言えば、異常があってもチェックランプがつかないように電球を抜いている状態である。
こうなるとサイトオーナー側はリスクを把握する術を持たない。
セキュリティは最優先事項であるという認識を持とう
アップデートによってデザイン崩れやエラーが発生した場合クレームになるのを恐れているケースもあると思うが、それは制作者の責任ではない。
そうしたリスクを低減する制作方法もあるが、そもそも開発時点のコアやプラグインの仕様に合わせてテーマなどは制作されている。
もしクレームになるとしたら、それはアップデートがあるということとその際に発生し得るケースを事前に説明していないためである。
しかしながら、それをしてもクレームになることもあるだろう。
その場合はこう考えて欲しい。
「デザインが崩れてもクレームになるなら、改ざん被害に遭って実害が発生したらもっととんでもないクレームになる」ということである。
セキュリティはすべてに優先されるのだ。
この考え方を制作者はクライアントと共有すべきであり、同時にユーザー企業側もこうした意識の元必要なメンテナンスについては許容する必要がある。こう書くのは、日に数十人しか来ないコーポレートサイトなのにメンテナンスを一切許容しないという例を多く聞くからだ。
本当にwebサイトを数秒だって落としたくないというのなら、相応のコストを負担すればおそらく制作者は対応してくれるだろう。問題はそのコストは負担せず、かつメンテナンスも許容せず、結果として被害に遭えば制作者、制作会社を責めるというパターンが往々にして見られることである。
Web改ざんは改ざんだけではないという事実、メール内容の流出
「大袈裟じゃないか」と考える人のために、もうひとつ。
Web改ざん被害があった場合、制作会社等でもサーバー内を確認し、被害を認識した上で当社にご連絡を頂くことが多い。
そして、オンラインカジノのサイトにリダイレクトされる、とか、ウイルスに感染しているという画面と電話番号が出ている、とか、つまり被害の結果として発生している事象を把握している場合が多い。
今この記事を読んでいる方の中にも、同種の経験をしたことがあるという方はいるだろう。
そこで閲覧者が詐欺に引っかからなければ問題は起こらない、あるいはリダイレクトされているだけだし、といった感想を持っている方が多いように思う。
しかしながら、筆者らはもっと違うことをいつも心配している。
それはメールの流出である。
多くのレンタルサーバーでは、web公開エリアの上にメールのディレクトリが存在しており、外部とやり取りしているメールのファイルが存在する。
そして、侵入者はこのメールディレクトリやファイルにもアクセスが可能である。
レンタルサーバーの場合、アクセスログやエラーログの他にこうしたログが取得できることは稀だが、それでも流出があり得るということは書いておかなければならない。
もっとはっきり言えば、実際に流出したケースに筆者らは一度ならず遭遇しているからだ。
取引先とのメールが流出しているかもしれない、というのは単なるリダイレクト等の改ざんよりももっと違う重みを感じないだろうか？
デザインの崩れやアップデート通知の停止は、こうしたリスクより優先されるものではないはずだ。
テーマの脆弱性
見落とされがちで、かつ割合としても多くはないが、一定の割合でテーマの脆弱性を悪用されるパターンがある。
これはデフォルトテーマなどではなく、制作会社が独自に製作したテーマや、販売されている有料テーマなどで発生している。
狙われる脆弱性として多いのは、SQLインジェクションなどの入力値検証不備である。
特に、WordPress 本体とは別のデータベースと連携し、一覧表示や絞り込み検索の機能を独自実装しているケースでよく見られる。
つまり、原因は「WordPressだから危ない」というよりも、外部連携部分を実装したコードそのものにあるということになる。
ふだんは WordPress のAPIやコーディングルールに沿って開発している制作会社であっても、そこから外れて素のPHP／SQLをスクラッチで書く場面になると、適切なバリデーションやプレースホルダを使わず、結果的に脆弱な実装になってしまうケースがある、ということだ。
典型的な攻撃パターンを回避するだけでリスクは大幅に下がる
さて、大きくログイン認証の突破、コアやプラグインの脆弱性という二つについてどう対応するか解説したが、これでほとんどの場合Webの改ざん被害を未然に防ぐことができる。
大したことではない、十分な強度を持つパスワードを設定し、できれば自動アップデートにするだけだ。
ログインURLを変えるかどうかやバージョン情報を表示しないといった対策はそもそも本質から大きく外れているので忘れて良い。
もちろん基本的なパーミッション設定などはできている前提ではあるが、WordPressのセキュリティというのは基本さえ抑えておけば問題ないということをよく知って欲しい。
関連記事
カテゴリ：WordPressセキュリティ
タグ：WordPress
