WordPressセキュリティの真実


公開日: 最終更新日:

WordPressのセキュリティについては、そのユーザー数の多さから様々な言説が語られてきた。

筆者は約12年間WordPressの不正アクセス被害の調査復旧に携わっており、手がけたWordPress被害サイトの数は今年4,500サイトを超えた。自ら4,500サイト以上を復旧した人は日本広しと言えどそうそういないだろう。また復旧調査以外にも数百サイトのWordPress保守を行っている。

さらに、WordPress以外の例えばEC-CubeやMovable Type、a-blog CMS、古くはZen CartやXoops Cubeといった各種CMSの被害復旧、調査も行ってきた。SymphonyやLaravel、CakePHPといったフレームワークで作られたwebシステムや、まるっきりフルスクラッチで作られたCMSなども同じように復旧、調査を行ってきた。

恐らくは多くのWeb制作者の皆さんよりWordPressセキュリティのリアルに触れてきたと思うので、ここにつらつらと書いておこうと思う。

また被害に遭いにくくする方法、そしてWordPress保守サービスの在り方についても触れておきたい。

完璧なセキュリティというものが存在しない以上、大前提としてセキュリティに「過剰な」コストをかける必要はないので、多くのサイトオーナーや制作会社の皆さんにとって適正な予算を考えてもらうための材料にしてもらいたい。

「WordPressはハッキングされやすい」というのは本当か

とても回答が難しく、かつ多くの皆さんが抱える疑問を最初に持ってきてしまった。

こう感じている人が多い最大の理由は、「実際に不正アクセス被害に遭い改ざんされたWordPressをみたことがある」とか、あるいは「クライアントのWebサイトが改ざんされた」といった話が制作者間でもなされることからリスクが非常に身近に感じられるからだろう。

実際被害に遭うWordPressの数は多いが、これはもうひとえにWordPressで作られたWebサイトの数が多いためである。日本におけるCMSのWordPressシェアは世界的にも高く、W3Techによれば2025年11月28日現在83.1%にのぼる。

https://w3techs.com/technologies/segmentation/cl-ja-/content_management

2024年に見た時は82%台だったので2025年になってもまだ増えていることになるが、こうなると被害に遭うCMSは大抵WordPressと言って差し支えない。

Movable TypeやEC-Cubeといった、シェア0.1%とか1%強のCMSが同様の被害発生率なら分母が小さい分ほぼ被害は生まれないことになるが、実際にはもう少し高い頻度で被害に遭っており、少なくとも当社に持ち込まれる頻度から言うと分母の割には多い。

これらのCMSも「セキュリティが甘い」のだろうか?

「外車はすぐ壊れる」、という言葉を聞いたことがないだろうか。

ほぼノーメンテでもトラブルを起こさない日本車に対し、ドイツ車など外国車は壊れるというものだ。

しかしドイツ車も基本的にメンテナンスをしっかりしていればそうそう壊れないし、何十万キロも乗れたりする。そう、メンテナンスが前提になっており、日本車のようにノーメンテを前提としていないため「壊れた」と感じる、あるいは本当に壊れるわけだ(なお、イタリア車やフランス車についてはメンテナンス以前の問題も多いため触れない)。

そして、WordPressは間違いなく「メンテナンスを前提」としたものである。

WordPressに限らず、すべてのCMSはメンテナンスを前提としている。EC-CubeもMovable Typeもメンテナンスが必要だし、各種フレームワークもメンテナンスが必要である。

なんならそれらが動くwebサーバもメンテナンスがあり、PHPもみなさんが経験してきた通りバージョンアップされていく。

改ざん等の不正アクセス被害について言えば、メンテナンスしなければ当然被害に遭う確率は高くなる。どのCMSを使おうが関係ない。

メンテナンスは絶対に必要であり、それをしなければリスクは高まる。

オープンソースだから危険!隠せばセキュアなのか?

WordPressはオープンソースであり、ソースコードが公開されている、ゆえに悪意を持った人物もコードを閲覧できるため危険である。これも大変よく聞く論調である。

なお、ソースコードや仕様を公開せず非公開のものをプロプライエタリと呼び、オープンソースの対極となる。

さあ、ここで「隠すセキュリティ」という概念について触れておこう。

隠すセキュリティのことをSTO(Security Through Obscurity、STO)と呼ぶ。

ソースコードや仕様が秘匿されていれば、脆弱性があったとしても悪用できない、という考え方である。

逆に言えば、秘匿されていなければ悪用されるわけでセキュアとは言えないということになる。

WordPressはとかく話題になりがちだが、制作者たちの多くが語るセキュリティ対策の多くはこの「隠すセキュリティ」の話であり、これを理解しないと実は話が進まない。

さて、「隠すセキュリティ」は実際のところサイバーセキュリティの世界では推奨されていない

大事なことなのでもう一度言うが、推奨されていない

これは「隠すセキュリティ」にのみ依存した場合、万が一脆弱性が明らかになった場合に防衛が不可能になるためである。

よく引き合いに出されるのは暗号におけるケルクホフスの原理である。

暗号方式は秘密にしようとしてもスパイによって設計書が盗み出されたり暗号装置ごと敵に捕獲されたりして、遅かれ早かれ敵に解析されてしまうことから、暗号方式は秘密であることを必要とせず、敵の手に落ちても不都合がないこと、という現在ケルクホフスの原理として知られている条件を含む、軍用暗号の条件を示した。

暗号の安全性を証明することは設計者や特定機関の評価だけでは難しいことから、アルゴリズムを公開して暗号の安全性を誰でも検討できるようにすることが暗号の規格として広く普及するための要件とされている。

この考え方はつまりソースコードや仕様が漏れたり解析されたりしてもなお安全なものを作らなければならない、ということであり、オープンソースもこうした考え方に基づきソースコードが公開されている。

なおセキュリティにかかわるものならだれでも知っていると言っていいNIST(米国立標準技術研究所)の、NIST SP 800-123 Guide to General Server Securityの2.4で、

System security should not depend on the secrecy of the implementation or its components.

としており、要するに「システムのセキュリティは、実装やその構成要素が秘匿されていることに依存すべきではない」としている。

このように、よりセキュアなシステムとして完成されるようオープンソースなのであって、一見正論に聞こえる「オープンソースだから危険」という考え方はそれ自体がそもそも間違っているということになる。

WordPressはアップデートしても被害に遭う!?

こういう声も聞く。

アップデートしても被害に遭うんじゃどうしようもなくね?やっぱセキュリティやばいんじゃね?!

そう思ったあなたは落ち着いて欲しい。

まず事実関係から整理するが、「WordPressはアップデートしても被害に遭う」そんなことがあり得るのか、と言われれば、なんとあり得る。

この理由には大きく分けて2つあり、一つはゼロデイと呼ばれるものだ。

ものすごく簡単に言えば、開発者も気づいていない、あるいは修正できていない脆弱性に悪意を持った誰かが気づいてしまい、悪用し、被害を出す場合である。

アップデートされた最新版に脆弱性があり被害が多発したケースとしては、コアの脆弱性が悪用されたケースがある。

二つ目は、もっと身近でほとんどの場合はこれと言って良い、パスワード強度の不足である。

どんなにコアやプラグインを最新版にしていても、パスワード強度が低ければ認証を突破されてしまうことがある。多い事例としては、こうして不正にログインされた結果ダッシュボードからプラグインやテーマの形でバックドアを含む不正なファイル群がアップロードされる、というパターンである。

ちなみにパスワード強度の不足に起因する不正アクセスも、WordPressに限らず発生し得るものだ。

また、強度が十分であっても使い回しされていてどこかで流出してしまっている場合は同様のリスクがある。

ログインURLがデフォルトだからそんなことが起こるのでは?

ログインURLを変更していないからそんなことが起こるのだ、ログインURL変更は基本!という声も聞く。

これが正しいかと問われれば、「無意味だとは言わないが本質はそこではない」というのが結論になる。

そう、これは先述した「隠すセキュリティ」だからである。

本来ログインURLが変更されていなくても安全な運用がなされなければならないのであり、そうした運用がなされていればそもそもログインURLが変更されていようがいまいが問題はない。

たとえば各種SNSは様々な人が同じログイン画面からログインするし、そのURLは公開されている。

隠さなければセキュリティを担保できない、といった考え方は誤っている。

readme.htmlやlisence.txtが閲覧できる!危険!

これも先述の「隠すセキュリティ」である。

この種のファイルが存在・閲覧できるとしても、せいぜいバージョン情報が分かるだけでこれが何らかの脆弱性というわけではない。

少なくともアップデートが適切になされていて既知の脆弱性がないのであれば、本来隠そうが隠すまいがどちらでも良い。

headタグのバージョン情報を隠すべき?

ここまで読み進めてきた皆さんならもう分かるだろう。

そう、これも隠すセキュリティである。

じゃあ有効なセキュリティ対策って何?一体どうしたら被害を防げるの?

ここまで、巷でよく言われているWordPressのセキュリティ対策について、その多くが「隠すセキュリティ」であることに触れてきた。

これは本質的な対策とは言えず、推奨されているものでもない。

またオープンソースだから危険、という言説も誤った考え方であることを示した。

ではどうしたらWordPressのセキュリティを向上できるのだろうか?

ここからは次の記事で解説することにしよう。

著者紹介: 増子貴仁

アバター画像Cross&Crown Security Intelligence LLC代表社員。
2013年、被害調査復旧に特化したWebRepairサービスを開始、以来2025年までに復旧を手掛けたWordPressの数は4,500サイト以上。趣味は登山、天体写真。

関連記事



カテゴリ:
タグ:,,



関連記事


記事はありませんでした