WordPress のユーザー ID が見えるのは何の問題もないし脆弱性でもない

事の発端は Web担当者Forum に寄稿されたプライム・ストラテジー社の記事
僕がなんでこんな怪文書を書かないといけないことになったかというと、
日本のWordPress 約15%がユーザーID丸見え、4割がログイン画面むき出し! 18万サイトを調査【プライム・ストラテジー調べ】
これである。
この記事では、WordPress のユーザー ID が丸見えだったり、ログイン画面がむき出しであるウェブサイトがたくさんあることを指摘している記事だ。
この記事は、根本的にすべてが間違っている。
なぜ「ユーザー ID を見えないようにする」が間違いなのか?
ユーザー ID が分かると、ログインに使用する ID が分かる。だからユーザー ID を見えないようにするべきだ。ということを指摘しているのだろう。しかし、これはどう考えてもおかしい。
ユーザー ID が公開されていて、なおかつユーザー ID でログインできるサービスはいくらでもある
Twitter もそうだしね。
ユーザー ID が推測されないものになっていないと意味を成さない
例えば、このブログ (Wangel – AioiLight.space) は僕 (AioiLight) が運営しているブログである。
では、このブログのメインのユーザー ID はなんだろうか? 考えてみよう!
答えは簡単、AioiLight
以外の何物でもない。
このように、たとえユーザー ID が見えないように “細工” したとしても、そのユーザー ID 自体が推測しやすい ID だったら、隠しても何の意味もない。そのため「ユーザー ID を見えないようにする」という対策が初めて効果が出るのは、完全にランダムなユーザー ID でアカウントを登録している必要がある。
あ、そうそう忘れてた。WordPress はメールアドレスもログインに使えるので、これに加えて推測されないメールアドレスにする必要もある。もちろん、ウェブサイトに掲載するメールアドレスとは別にね。誰がそんなことするねん……。
特定のページを変えただけでは、完全に隠しきれない
プライム・ストラテジー社の記事では、特定の URL にアクセスして ID が見えるかどうかを確認している。
しかし、ユーザー ID はそれ以外の様々な場所にも出てくる。その URL に対してアクセスを制限しただけでは、ユーザー ID が漏れ出すのを防ぐことはできない。
本当に完璧に対策するとなると、WordPress がどこでユーザー ID を出力するかをすべて把握した上で、それをすべてオーバーライドする必要がある。そんなの現実的ではない。
そもそも、WordPress は問題だと思っていない
WordPress は世界各国の素晴らしい開発者によって作られているソフトウェアである。
……みたいなクサい前置きは置いておいて、こちらを見ていただきたい。これは WordPress.org のページの一部である。
The WordPress project doesn’t consider usernames or user ids to be private or secure information. A username is part of your online identity. It is meant to identify, not verify, who you are saying you are. Verification is the job of the password.
This includes, for example, retrieving the list of site users through the REST API Users endpoint,
GET /wp-json/wp/v2/users
. Making this publicly accessible is intentional.Generally speaking, people do not consider usernames to be secret, often sharing them openly. Additionally, many major online establishments — such as Google and Facebook — have done away with usernames in favor of email addresses, which are shared around constantly and freely. WordPress has also moved this way, allowing users to log in with an email address or username since version 4.5.
Instead of attempting to hide a public identifier, WordPress attempts to encourage users to choose strong passwords instead, through both user interface as well as education.
Note that WordPress is not the only open source project to believe this. Drupal has similar arguments for the same thing.
Why are disclosures of usernames or user IDs not a security issue?
(ChatGPT に「おもしろおかしく翻訳して」とお願いしたもの) WordPress的には、「ユーザー名がバレた? だから何?」って感じ。だってユーザー名は「俺だよ俺!」って名乗るためのものであって、「マジで俺?」って確認するためのものじゃないからね。そこはパスワードの仕事。たとえば、WordPress の REST API (GET /wp-json/wp/v2/users
) を使うと、サイトのユーザー一覧が見れちゃうけど、これも「隠す必要なくね?」ってことで、わざとそうなってる。ていうか、みんなユーザー名を秘密にしてないでしょ? Twitter とかで「俺のアカウントは~~だぜ!」って自分から言ってるし。Google や Facebook も「もうユーザー名いらなくね?」ってなって、メールアドレスでログインする方式にしてるし、WordPress もバージョン 4.5 から「好きな方でログインしていいよ!」って感じになってる。だから WordPress のスタンスは、「ユーザー名を隠せ!」じゃなくて「バカみたいに強いパスワードを設定しろ!」ってこと。 UI とかでも「そんなパスワードじゃ秒で破られるぞ!」って注意してくれるしね。ちなみに、この考え方は WordPress だけじゃなくて、Drupal とか他のオープンソースプロジェクトも同じノリ。要するに、「ユーザー名とかどうでもいいから、とにかくパスワードはちゃんとしとけ!」って話。
WordPress 界隈はあまりにも間違ったセキュリティ対策が多すぎる
WordPress は様々なレベルの人が使うソフトウェアなので、残念ながらインターネット上には間違ったセキュリティ対策を進めている記事がたくさん見つかる。
例えば、以下のような「セキュリティ対策」と謳われているものは、僕はあまり意味がないと考える。
- 管理者のユーザー ID を見えないように工夫する
- 先述したとおり。
- ログイン画面の URL を変更する
- ログイン URL を変えたとしても、攻撃する側は変更先の URL をサーチする (変更するプラグインが一定の法則性を持っているため)。
- そもそも WordPress には「メタ情報」というウィジェットがあり、そこにログイン画面へのリンクがある。少なくとも WordPress は、ログイン画面が露出していることが問題であるとは考えていないようだ。
- 本当に必要ならログイン画面の URL を変える機能を WordPress 自体に実装するんじゃない?
- ログイン画面に画像認証を追加する
- 今なら画像を入力できるマルチモーダル AI がありますしね。
- データベースのプレフィックスを変える
- そもそも、インストールするときに「セキュリティのため、変更してください」と書かれていましたか?
- 「複数の WordPress をインストールする場合は変えてください」としか書かれていないはず。
- つまり、そういうことです……。
- WordPress のバージョンが出力されないようにする
- 恥ずかしくないように、最新版にアップデートしてください (笑)
- CSS の読み込みなどに付加されるバージョンは、キャッシュ破棄にも役立つので必要
- REST API を無効化する
- REST API はアプリケーション認証なので、ログインのパスワードは関係ない
- あと普通に WordPress の根幹である機能が死ぬのでダメ
下記のような対策も、僕は意味があまりないと考えているが、僕はセキュリティの専門家ではないので断言するのは控えておく。
- BASIC 認証を導入する
- これは公式のドキュメントでは推奨されている。ただ、2 要素認証を設定して、かつ XML-RPC の一部が無効化され、パスワードのみでログインできる経路を潰している状態ならば、BASIC 認証を設ける必要性はないのではないか、と考える。
- どのみち通常のパスワード + BASIC 認証だけだと「多要素認証」にはなっていない。
- ただ、BASIC 認証よりも IP 制限の方が強力なので、どちらかというと BASIC 認証は IP 制限できない環境での代替案みたいな側面がある。はじめから IP 制限が掛けられるならそっちの方が良いに決まっている。
じゃあ、どうすればいいのか?
基本は下記の対策をしてれば良いと思う。
- 「基本」に忠実にこなす
- 「基本」というのは、パスワードを十分に強固なものにすることと、定期的にアップデート (WordPress に限らず全て) すること。これらが何よりも一番効く。
- 不要なプラグインを消す
- プラグインの中には設計が甘くて脆弱なものもある。無駄にプラグインがあっても嬉しいことは全くないので、必要最低限のものに絞る。使用しなくなったものは、無効化だけでなく完全に削除する。
- 2 要素認証を設定する
- TOTP を提供するプラグインがあるので、それを使う。少なくとも、画像認証が出てくるよりは間違いなく良いに決まっている。
- XML-RPC の認証が必要な部分を無効化する
- 2 要素認証を追加するプラグインを入れたとしても、XML-RPC はパスワードがあれば操作できるような状態になっている (なので、モバイルアプリではパスワードをだけでログインできてしまう) ので、完璧な対策にはなっていない。
- XML-RPC の認証が必要な部分を無効化することで、パスワードのみでログインできる経路を潰して、2 要素認証を必須にする。
- WAF を導入する
- 余裕があるなら (資金的に?)
- IP 制限を掛ける
- VPN なりを使えば、IP 制限を掛けながらもどこからでもアクセスできるようになる。
さいごに
ともあれ、一番良くないのが「大して意味もない対策をして、対策をした気になっている」というもの。
意味があること・ないこと、全てしらみつぶしにやるならまだマシで、意味がない対策だけしてそれで終わりになっているという状態には、ならないでほしいと願うばかりである。
プライム・ストラテジー社の製品 (KUSANAGI) は素晴らしいし、それを使用している僕からすると、同社のこの記事は残念に思う。