Scribble at 2023-04-25 11:13:56 Last modified: 2023-04-25 12:46:59

たまたま手に入れた WordPress の本（ただし2015年のもの）を読みつつ「WordPress のセキュリティ対策」というページに色々と手を入れている（この本そのものには、あまり参考になる知見はなかった。既に当サイトの論説で解説している内容を越える事項はない。ユーザのロールは丁寧に説明してあるが、たいていは運営する本人のロールを別の弱いユーザとして使い分けるかどうかの問題だろう）。いったんは公開したページなら、そのメンテナンスも著者の責任というものであろう。思想を述べたような本であれば過去に論じた内容を保つことに意味があると言える場合も多いが、技術的な内容は常に更新しないと現行技術や実務とのミスマッチを読者に引き起こすため、端的に言って「嘘つき」になってしまう。

というわけで、たとえば WordPress だと最近は wp-config.php をインストール・ディレクトリとは別の階層へ置けるようになってるよーという注釈をつけていたのだが・・・これだめじゃん。

何が駄目かというと、wp-config.php を探しているのは wp-load.php なのだが、そのコードを実際に見ると、

@file_exists( dirname( ABSPATH ) . '/wp-config.php' )

なんてものを探している。ABSPATH は __DIR__ のことなので、これはつまりインストール・ディレクトリの一つ上の階層を見ているだけだ。これだと、たとえば多くのサイトでは /wordpress とか /wp なんてディレクトリをルート・ディレクトリの下に掘って、WordPress の一式をデザイナー様やコーダ様のクリエーティブな作業の邪魔であるかのように扱うわけだが、こうすると wp-config.php は /wp の上の階層、つまりルート・ディレクトリに置くことになる。すると、.htaccess や Apache に問題が起きて .php ファイルへブラウザでアクセスするとテキストとして表示されてしまうような状況になってしまうと（PHP やサーバの設定ミスで起きることもある）、wp-config.php にもブラウザでアクセスできてしまい、データベースのパスワードが丸見えとなってしまう。

僕が期待していたのは、インストール・ディレクトリではなくルート・ディレクトリの一つ上の階層に置けるということだ。それなら、ウェブ・サーバのアプリケーションに問題が起きてもブラウザでルート・ディレクトリの上の階層にはアクセスできないから wp-config.php は安全だ。ルート・ディレクトリに WordPress を展開していたら、それは実質的に同じ挙動となるので気づかないわけだが、wp-load.php を見ると、WordPress のインストール先によってはルート・ディレクトリの上の階層に wp-config.php を置けないということになる。

もちろん、敢えてそうしたという可能性もある。なぜなら、ルート・ディレクトリを共有して複数の WordPress をインストールするという可能性もあるからだ。/div1/wp, /div2/wp に二つの WordPress を置いて、部署ごとに運用させるといった会社もあった（この場合なら、/div1/wp-config.php と /div2/wp-config.php という別のパスに同じファイル名のファイルを配置できる。ルート・ディレクトリの上にパスが固定されると、異なる内容の同名ファイルは置けない）。そして、一方は最新版にアップデートしていながら他方は２年前のままという酷い場合もある。でも、最新版の WordPress を使いたい部署が PHP もアップデートしようとすると、最新の PHP に対応できないという理由で古い WordPress を使ってる部署が反対して・・・という、大企業ならでわの愚かなことを何年も延々と続けて、しまいに「これ使い難いよね」と自分たちの愚かさが理由であることにも気づかず、こっそり忍び込んだ IT ゼネコンとか事務機屋の営業にそそのかされて、クズみたいなオリジナル CMS を数億円で構築する予算をとったりする。そして、そのコストを「インフレ対策」とか「社員のワーク・ライフ・バランス」と称して消費者に転嫁したりする。

そういや、こういうこともあるだろうからって理由で、WordPress Mu というマルチサイト対応の WordPress があったんだけど、もう開発は止まったようだ。僕も Automattic の決定は正しいと思う。

で、僕はどういうことをやってるかというと、当サイトの論説でも解説しているように（ということは、僕らのようなレベルの人間にとっては５年ほど前のアイデアにすぎない）、インストール・ディレクトリには普通に wp-config.php を置いて、そこに設定内容を書かなければいいだけである。つまり、その wp-config.php には、

<?php require( '/var/www/lib/wp-config.php' ); ?>

という本当の設定内容が書かれたファイルの呼び出しを記述するだけである。WordPress はアップデートされても wp-config.php を勝手に書き換えたりはしないので、どういう内容を書いていようとアップデートで上書きされてしまう心配がない。ということは、逆に言えばどういうコードを書いていてもいいのである。WordPress を更に安全かつ有効に扱うためには、PHP の開発経験を持っているエンジニアが携わった方がいいのは、こういう点でも分かるだろう。これは僕が天才だからではなく（有能ではあると思うが）PHP を扱えるから思いつくことなのだ。コピペで「ワードプレスのセキュリティたいさく」なんてコタツ記事を書いてる連中には無理な思考・仕事である。

それから、Stack Overflow などでは wp-config.php を別の階層へ対比することが有効かどうかという議論があって、この対策が有効ではないと反対する人々がいたということも、僕の論説では紹介している。この議論に一つだけ補足しておくので、ここでもご紹介しておこう。

wp-conifg.php を退避することが有効である理由の一つは、サーバの問題に起因して wp-config.php がテキストとしてレスポンスされてしまう可能性を排除することである。すると、PHP が動かなくなったサーバでは、プライベートなネットワークだけに制限してアクセスを許可してあるようなデータベースに対しては、どのみち PHP が動かないサーバからしかクエリを送る方法しかないので、結局はデータベースにアクセスされる経路が絶たれるのだから被害は起きないという人がいる。

僕は、サーバ管理の技術者として言わせてもらえば、こういう意見は非常に深刻な無知を示していると思う。なぜなら、サーバのトラブルというものは、WordPress どころかサーバの管理者ですら気づかないうちに起きて、そして復旧してしまうことすらあるからだ。pkg_update なり apt なり dnf なり yum といったパッケージ管理ツールで自動更新をかけている場合、更新したアプリケーションなりパッチを適用して再起動したら問題が起きてサーバが停止してしまうということはある（ウェブとは別だが、Windows Update なんて新しいトラブルの宝庫であり、バグの追加パッチとすら言われる）。あるいはアプリケーションが更新されたパッケージと相性が悪くて問題を起こすこともあろう。そして、すぐに新しいパッチがリリースされて、再び自動更新で問題が解消されるということもある。そもそも、サーバのトラブルが起きていることに管理者が常に気づけるなんて想定をしている時点で、そういう人物は情報セキュリティの実務を語る資格がないと思う。情報セキュリティにおいて、政府から家庭にいたるまで妥当な予算が投じられていても十分ではない対策がモニタリングであるのは常識だ。サーバを攻撃する側は、これは史実ではないと言われているが、「遠からんものは音に聞け、近くば寄って目にも見よ」などと武将の一騎打ちのように大声を出して攻撃などしない。いかに気づかれずに攻撃して成果を得るかが重要であり、相手が気づかなければ再び同じ手法が使えるかもしれないし、更に効果的な手法があればもっと悟られにくいと期待できる。