WordPressの脆弱性

98パーセント

WordPressの脆弱性のほとんどは、本体ではなく「プラグイン」や「テーマ」に存在します。これらを悪用されるとサイトの改ざんや情報漏えいにつながる恐れがあります。

脆弱性の大部分はプラグインやテーマから発生しています。

大部分といってもわかりにくいですが、98パーセントと言われると、もう「ほとんど」といってよいと思います。

実はこの間のEmDashの話を書くのに色々資料を読んでみて思ったのですが、WordPressのプラグイン由来の脆弱性って、実はきちんとファイルを整理して、MUプラグインを丁寧に活用して、プラグインはきちんと理解しているものを最小限、としていったら、かなり防げるものが多いのではないかと思ったのです。


Tea World方式

Tea Worldの

  • プラグインは最小限
  • 理解しているものだけ使う
  • 自作できる小機能はMUプラグインへ
  • functions.phpに集めない
  • CSSも所在を明確にする

は、セキュリティ面でもかなり理にかなっていると思います。

ただし一点だけ注意で、MUプラグイン自体が安全なのではなく、管理された自作コードを、責務ごとに置けるのが強い、ということです。

MUプラグインは常時有効で通常プラグインより先に読み込まれる仕組みなので、便利な反面、混入された悪意あるコードも残りやすい場所になり得ます。なので結論は

WordPress防衛の第一歩は、セキュリティプラグインを増やすことではなく、知らないコードを減らすこと

だと言えるでしょう。


プラグイン由来の脆弱性

WordPress プラグインは

  • DB触れる
  • 投稿触れる
  • 管理画面触れる
  • REST API触れる
  • upload触れる
  • AJAX触れる

ので、権限がかなり強い。だから、

便利=攻撃面積が増える

となりやすいのです。だから整理して入れることが大事なのです。

将来的には、AIが常時監査して

このプラグイン、

  • 未使用コード多いです
  • REST公開広すぎます
  • nonce不足しています

みたいに即時警告できるようになるでしょう。実際技術的には今でもかなり可能です。

でもその結果を伝えられて実際に手を打てるユーザーがどのくらいいるのか考えると、ちょっと悩んでしまいます。

近い将来AIは、

  • このプラグイン危険です
  • このコード古いです
  • nonce不足です
  • SQL危険です

などまではかなり高精度で言えるようになると思います。でもその先、

どう直す?

で止まってしまったり、

怖いから触れない

になる可能性が高いのではないでしょうか。


くまのWordPress五則

WordPressの脆弱性に関して言えば、まづ次の四則が言えると思います。

  • 面倒がらないこと
  • 怖がらないこと
  • 手間を惜しまないこと
  • 細かいことを嫌がらないこと

これが「基本四則」だと思います。

例えば最初はpage.php、single.php、archive.php、CPTが全部子テーマ直下。

でも、途中で「これtemplateフォルダで独立させた方がよくない?」と思う。

とはいえ、その作業が終わったところでサイトの見た目が変わるわけでもないし、サイトの内容が充実するわけでもない。保守管理も今までできていたわけだし……と、やらない言い訳はいくらでも出てきます。

そこで、最初の「四則」に加えてもう1つ。

「気が付いちゃったらやりましょう」

を加えましょう。

それだけでずいぶん違うと思うし、プラグインもやたらとわからないものまで入れるはなくなってくると思うし、今後AI支援が高度化すれば脆弱性もかなり防げると思います。


五則の元

これたぶん、くまが食品工場で食品衛生と品質管理の総責任者経験をしているというのが結構あると思います。

食品衛生や品質管理って利益を生まないし、お金かかるし、経営サイドからは「もっとタイトにできない?」といつも言われる。 だけどこれが崩れたら一瞬で工場が止まり、商品がなくなり、営業も止まる。 でもうるさがられる(笑い

だけど、そういう目に見えない、利益に直結しない、手間と費用が掛かる、そういうものが全体を支えているというのを嫌というほど経験しました。それに、実際私が辞めただけで工場含めて会社が3つ倒産しました。 だから、見えないところの整備の大切さは実感として知っているのです。これは大きいと思います。

食品衛生や品質管理って、本質的には

「事故が起きない状態を維持する仕事」

です。しかも厄介なのは、

問題が起きなければ、起きないほど、 存在価値が見えなくなる

ということです。だから経営側から見ると、もっとタイトにできるのではないかという締め付けをしてしまいがちになるのです。

でも大事なのは、問題や事故が起こらないように維持すること、なのは自明です。


構造化と説明できる構造の意味

やるべきこととその理由

ようするに、きちんと仕分けして、構造化して、どこに何があるかわかるようにしておく、という極めて当たり前のことを、ここまでかけて言っているのにすぎません。

しかもこれからAIは絶対(くまは絶対という言葉は基本使わないのだけどこれは絶対といっていい)に進化します。

その時、AIに理解しやすい構造やAIに手伝ってもらいやすい構造を作っておけば、円滑に運ぶのは目に見えています。

もちろん、その「整える作業自体をAIにまかせる」という発想もあるかもしれないし、可能ではあると思うけど、そこには「とんでもないロス」が出る上に、人間が「どう整理してもらったか理解できない」可能性が高いです。そうなったらもう協働は根底から崩れてしまいます。


WordPressの話に戻せば

Tea World式の

  • 命名統一
  • 責務分離
  • template整理
  • loader文化
  • MU plugin分離

は、実は単なる整理整頓ではなく、

「AIと人間の共通言語を作る」

行為になるのです。そしてこれ、食品工場時代の品質管理思想とも完全につながっています。つまり、

  • 誰が見ても追跡可能
  • 誰が見ても理解可能
  • 問題が起きた時に遡れる

という思想です。

これは未来のAI協働で、ものすごく重要になる気がします。そしてこの「共通言語」こそが今後大きなキーワードになってくるのは間違いないと考えます。