KUSANAGI開発元が語るユーザー体験を高めるWeb運用 ― 第7回

正しく恐れて正しく運用。WordPressの脆弱性とアップデートのキホンを理解する

　こんにちは。KUSANAGIの開発チームで取締役をしている相原です。

　「KUSANAGI」はWordPressをはじめとするCMSを高速に動作させる世界最速クラスの仮想マシンです。わたしたちは「KUSANAGI」を開発して皆様にご利用いただくほか、お客様のWebサイトを「KUSANAGI」で運用しています。

　この連載では、「KUSANAGI」の開発やお客様とのお話の中で感じた課題や実際の運用の中で得た知見などをお伝えしています。

　1月にWordPressに2つの大きなアップデートがありました。ひとつは脆弱性に関するマイナーアップデート、もう一つはメジャーバージョンアップです。

WordPress 5.8.3 セキュリティリリース
WordPress 5.9 Josephine

　WordPress 5.8.3 セキュリティリリースでは以下の4件の脆弱性への対応が行なわれました。

【CVE-2022-21662　投稿のスラッグを介して格納型クロスサイトスクリプティング（Stored XSS）攻撃が可能な脆弱性】
この脆弱性は投稿を公開できるユーザーのみが利用できます。

【CVE-2022-21663　マルチサイトインストールでのオブジェクトインジェクションが可能な脆弱性】
この脆弱性はマルチサイトのWordPressサイトのみに影響し、悪用するにはスーパー管理者権限が必要なため、影響のあるサイトはごくわずかであるとされています。

【CVE-2022-21661　WP_Queryを介したSQLインジェクションの脆弱性】
この脆弱性はWordPressコアを介して直接悪用されることはありませんが、一部のプラグインとテーマはSQLインジェクションを可能にする方法でWP_Queryを使用する場合があります。

【CVE-2022-21664　WP_Meta_QueryのSQLインジェクションの脆弱性】
WP_Meta_Queryを経由して発生する脆弱性でバージョン4.1～5.8のみが対象となります。

参考：https://www.wordfence.com/blog/2022/01/wordpress-5-8-3-security-release/

　「さあ、みなさん、アップデートしましょうね！」で終わってしまってはもったいないので、今回はWordPressの重要なセキュリティ対応のひとつであるアップデートについてお話したいと思います。

WordPressのバージョンの考え方

　WordPressのアップデートについて考えるときには、WordPressのバージョンの考え方を理解しておくとよいです。

　WordPressにはメジャーバージョンとマイナーバージョンがあります。小数点一桁目までがメジャー、小数点二桁目がマイナーのバージョンの番号です。

WordPressのメジャーバージョンとマイナーバージョンの違い

　WordPressのメジャーバージョンとマイナーバージョンは役割が異なります。メジャーバージョンでは大きな機能の追加や改善が行なわれます。新しいデフォルトテーマが追加されることもあります。マイナーバージョンでは主に脆弱性の対応やバグフィックスなどの対応が行なわれます。

WordPressの脆弱性対応は過去のバージョンにも適用される

　WordPressは世界中で最も多く利用されているCMSですから、脆弱性があった場合の影響度も大きなものとなります。すべてのユーザーが常に最新のメジャーバージョンを利用しているわけではないので、一定の過去のバージョンまで遡ってアップデートが適用されます。

　WordPressのリリース一覧のページをみてみましょう。

　2022年1月6日にバージョン5.8.3セキュリティアップデートがリリースされており、4.1 ブランチ以降でほぼ同時期にマイナーバージョンがリリースされているのがわかります。

 

※WordPressはオープンソースで世界中のエンジニアの協力のもと開発が行なわれているものですから、過去のバージョンに対するアップデートが補償されているものではないことに注意が必要です。また、過去のバージョンのみに存在する脆弱性は修正されない可能性が高いです。基本的にはメジャーバージョンアップを適用しながらマイナーアップデートを確実に適用するという運用が理想です。

WordPressのマイナーアップデートは怖がらずに

　WordPressのアップデートは「エラーがでたらどうしよう？」という不安でなかなか実施できないという話を聞きますが、メジャーとマイナーの違いを知っていれば、マイナーバージョンアップは影響範囲が少なく、それほど恐れる必要がないことがわかりますね。

　特に「脆弱性の対応」が含まれる場合は迷わず実施する、が正解です。

「ゆっくり検証して～」は間に合わない場合がある

　WordPressに限らず、脆弱性の対応に関するアップデートはゆっくり動作検証してから適用しよう、では間に合わない場合があります。

　WordPress 4.7.2ではいくつかの脆弱性の修正が行なわれましたが、実は重要なひとつの更新の内容が公開されていませんでした。2017年とだいぶ前の話になりますが、当時とても話題になりましたので知っている方も多いかもしれません。

　簡単に概要を紹介します。

　WordPressのREST APIに関する脆弱性がSucuriによって報告されました。WordPressの修正をおこなっている間、Sucuriはこの脆弱性をブロックするWAFのルールを追加、続いてSiteLock、Cloudflare、IncapsulaなどのWAFを使用している企業が協力してルールを作成し、脆弱性が利用されていないかの監視を行ないました。

　そして修正を適用したバージョンが公開され、何百万ものユーザーが自動アップデートによってこの脆弱性の存在を知る前に無事保護されました。

　また、自動アップデートを適用していないユーザーにもアップデートが適用されるための時間を確保するため、該当の脆弱性に関する開示を1週間程度遅らせたため、さらに多くのユーザーを保護することができました。

※Disclosure of Additional Security Fix in WordPress 4.7.2

　複数の企業が連携してオープンソースのプロダクトであるWordPressの多くのユーザーを保護したというすばらしい話です。

　そしてここにひとつの教訓があります。

　「アップデートの動作検証をゆっくりしていては間に合わない場合がある」

　この話のように、セキュリティの情報が開示されないことはまれです。わずかな日数の間に攻撃をされる可能性は考えておかなければいけません。

WordPressの自動アップデートは無効にしない

　WordPressには本体の自動アップデートの機能が備わっています。エラーのリスクも少なく、脆弱性の修正に素早く対応できるWordPressの自動アップデートの機能はとても大切です。無効にするなどというもったいないことはせず、有効にしておきましょう。

大事なときにアップデートがきたら？

　即時適用が原則のマイナーアップデートですが、実際に運用しているサイトではどうしてもこのタイミングにアップデートが走ってほしくないときがある、ということもあると思います。アップデートのタイミングがコントロールできたらよいですよね。

　「KUSANAGI」には自動更新のコントロール機能があります。翻訳・プラグイン・テーマ・WordPressコア（マイナーのみ/すべて有効）のアップデートの適用の有無と更新スケジュールが管理できます。

 

　キャプチャはプラグインの自動アップデートのみ無効とし、午前3時にアップデートが適用されるスケジュール設定をしている例です。このようにユーザー影響の少ない時間に設定しておくことでも積極的に自動アップデートを適用できるようになるのではないでしょうか。

　どのようなアプリケーションを利用していても脆弱性のリスクが0になるということはないでしょう。アップデートは怖いものではありません。

　「正しく恐れ、正しく運用する」

　これがアプリケーションと脆弱性との付き合いの基本だと考えています。

■関連サイト

• プライム・ストラテジーのサービス