WordPress5.3で更新エラーが出たらWAFを疑え

こんにちは、ブログ担当の内海です。

先日、今年初めてのブログ更新をすべく、チマチマと書き進めては下書き保存を繰り返していた私ですが、ある日突然起こったエラー地獄に悩まされてしまいました。

そのエラー内容とは、下書き保存時をクリックした後、間髪をいれずに出てくる「更新に失敗しました。 エラーメッセージ: 返答が正しい JSON レスポンスではありません。」というエラーメッセージ……。

このエラーが一度出てしまうと、直前に追加した画像や装飾などを戻さない限り保存ができなくなってしまうのです。

当社のホームページではレンタルサーバーを使用しており、テスト環境用のサブドメインを取得して裏で稼働させていますが、こちらでも同様のエラーが出てしまう状況でした。

ちなみにトラブルに見舞われていた当時のツイートです↓

結論から先に言うと、なんとサイトを外部からの攻撃から守ってくれるはずのWAFが原因でした。

WAFとは何か？どのようにして解決したのか？
今回の記事ではこれらについて解説するとともにトラブル解決までの一連の流れをまとめていきたいと思います。

解決方法をいち早く知りたい方は5.解決方法まで飛んでください。
トラブルが起きている皆さんのお力添えになればと思います。

目次

1.当社ホームページの環境

まずトラブルが起きた当時の環境について書き出しておきます。
何れも2020年2月現在、当時の最新バージョンを適用していました。

WordPress：5.3.2
PHPバージョン：7.3.13
使用ブラウザ：グーグルクローム 80.0.3987.106
レンタルサーバー：お名前ドットコム 共用サーバー
サーバーソフト：Apache 2.2.34
使用テーマ：Lightning 8.2.4

2.エラーが起きる要素と状況

更新エラーが起きる要素を箇条書していきます。

• 記事中に10～20数枚以上の画像の挿入
• 記事中数カ所の文字にこのような蛍光マーカーを入れた後、特定の箇所付近に蛍光マーカーを入れる
• 記事中に10～20数個以上の↓のようなフキダシを入れる

フキダシは←のように画像を指定した時はもちろんダメですし、↑のように画像を選択する前のデフォルト状態でもダメでした。

画像に関しては画像ブロックを入れただけではエラーは起きず、メディアを選択後にデフォルトのまま下書き保存するとエラーが起きる場合と、メディア選択後に画像を中央揃えにするとエラーが起きる場合がありました。

特に、画像や蛍光マーカーは特定の場所付近に使用するとダメで、少し離れた文末の方では大丈夫という状況だったのが難解でした。

また画像は一辺が800px以下になるようにサイズを縮小しているので、一番重くても200KBほどしか無いものしか挿入していません。

その時のツイートがこちら↓

さらに、エラーが起こる条件として画像の数とフキダシの数とで反比例している(画像の数を減らせば吹き出しの数を増やしてもエラーにならない)ようだったので、エクセルで表作ってまで確かめてみたりもしました。

○と×の境目あたりを検証しただけで、全ての組み合わせを試したわけではありませんが、大体こんな結果になりました。

ですが、表をよく見てもらえば分かる通り、画像11個とフキダシ4個の時と画像10個とフキダシ6個でエラーが出ていた事もあり、それ以上の数は挿入出来ない状況の時もあったので、エラーが出る条件に一貫性が無く……

結局、よく分かりませんでした。

3.解決のために行ったこと

解決のために色々手を尽くしていましたが、代表的なものを箇条書きしていきます。

ですが、以下のことを行っても一向にエラーは無くならず、頭を抱えてしまいました。

• 新規投稿を作成し、エラーの起こる記事から文章を手動で移植
• WP Multibyte Patch以外の全てのプラグインを停止
• テーマの変更(Lightning ⇒ Twenty Twenty)
• ブラウザキャッシュのクリア、及びブラウザの変更(Chrome ⇒ IE、Firefox)
• WordPressダウングレード(5.3.2 ⇒ 5.2.5、5.1.2)
• PHPダウングレード(7.3.13 ⇒ 7.2.26)
• PHP.iniの編集(画像アップロード上限アップ 2M ⇒ 50M、エラーが出るまでの秒数アップ 30秒 ⇒ 180秒)
• WAFを無効化

これを見ていただければ分かる通り、実は一度WAFの無効化を行っていました。

ですが、エラーは相変わらず無くならなかったのでWAFは関係ないと思いこんでしまったのです。
これが最大の落とし穴でした。

当環境ではWAFの設定はレンタルサーバーのコントロールパネルから有効無効を設定するのですが、即時反映されるわけでなく、変更から反映されるまでに実は一時間程度かかるというのです。

これに気付かず、WAFを無効にしてもエラーが消えないことからこれが原因ではないと判断してしまい、一度は犯人に近づいたもののまた遠ざかってしまったのです。

というのも、この後にWordPressのエラーログで怪しそうな箇所を見つけてしまったからです。

WordPressには開発者向けにデバッグモードというものあり、これを有効にしておくと何か不具合が起こったときにエラーログのファイルを生成してくれるのですが、更新エラーを起こすと必ず下記3つのエラーがセットで吐き出されていたのです。

1. [【エラー発生日時】] PHP Notice: Trying to get property ‘ID’ of non-object in 【中略】 /wp-content/plugins/vk-all-in-one-expansion-unit/inc/sitemap-page/sitemap-page.php on line 68
2. [【エラー発生日時】] PHP Notice: Trying to get property ‘sns_share_botton_hide’ of non-object in 【中略】 /wp-content/plugins/vk-all-in-one-expansion-unit/inc/sns/function_snsBtns.php on line 181
3. [【エラー発生日時】] PHP Notice: Trying to get property ‘ID’ of non-object in 【中略】 /wp-content/plugins/vk-all-in-one-expansion-unit/inc/sns/function_snsBtns.php on line 35

エラーの中にある「vk-all-in-one-expansion-unit」というのは、当ホームページが使用しているテーマ「Lightning」を制作している会社BizVektorさんが提供しているプラグインで、ホームページの様々な装飾を担ってくれているとてもありがたい存在なのですが、どうもこれが怪しいと思ってしまうように。

それもそのはずで、前述したフキダシブロックは「vk-all-in-one-expansion-unit」プラグインによる機能でしたし、蛍光マーカーもコードエディタを確認するとクラス名に「vk_highlighter」というものが使われていた(BizVektor製のものは必ず頭にvkが入っています)ので、余計疑いに拍車がかかってしまいました。

犯人を見つけたと思いこんでしまい、誤認逮捕してしまった時の様子↓
(ツイート内でプラグイン停止で更新エラーが無くなったというのは勘違いだったようです)

それから「vk-all-in-one-expansion-unit」の設定を変えてみたり、プラグインのダウングレードを行ったりもしましたが、当然ながら前述した通り、テーマを変えようが全プラグインを停止しようが更新エラーは消えなかったわけなので、これが原因ではないことは明白でした。

「vk-all-in-one-expansion-unit」のフォーラムでは有料版ライセンスを取得しているユーザーのみしか書き込みができないようだったので、wordpress.orgのフォーラムに不具合の報告を入れようとまで思い立った直前、もう一度WAFを洗い直すことにしたことで本当の真犯人を見つけることになりました。

思い込みって怖いですね。
(BizVektorさん疑ってすみません……)

WAFをもう一度洗い直すことにしたきっかけ

更新エラーを直す方法を探すためネットの海をさまよっている最中に「Classic Editor(クラシックエディタ)」プラグインを導入しているとエラーが起きないというのを見かけました。

クラシックエディタとは現行のブロックエディタ以前に使われていた投稿方式をWordpress5以降でも再現することが出来るプラグインです。

これを早速導入してみたところ、なんと当環境でもエラーが出なくなりました。

しかしエラーが出なくなったとはいえ、このままクラシックエディタを使い続ければいいというわけにも行きませんでした。

理由としてはクラシックエディタはいずれ廃止される可能性があること、ブロックエディタで作成した過去の記事がクラシックエディタでは表示崩れを起こしてしまっていたことなどがありました。

ですが、クラシックエディタでは問題がなくなったということが分かったおかげで、ブロックエディタが何か問題を起こしているという考えに至りました。

そして結果としてWAFが原因だということを特定することが出来たのです。

4.WAF(ワフ)とは？

WAF(ワフ)について少し説明しますと、正式名称はWeb Application Firewall(ウェブアプリケーションファイアウォール)というもので、文字通りウェブ上で使われるアプリケーションに特化したセキュリティシステムです。

簡単に言うと、自分のサイト上に悪意のある人物から一種のウイルスの仕込まれたりして、サイト訪問者の個人情報やクレジットカード情報などを盗まれないようにするためのものです。

ちなみにファイアーウォールという名前はついていますが、単なるファイアーウォールはネットワークレベルの通信を監視するもので、ウェブアプリケーションレベルを監視するWAFとは別物です。

WAFによって防げるとされている代表的な攻撃は以下のとおりです。

• SQLインジェクション
• クロスサイトスクリプティング
• OSコマンドインジェクション
• DDoS攻撃

具体的な攻撃内容の説明についてはここでは省きますが、これらは何も大企業のホームページばかりが狙われるのではなく、当社のような中小企業も同様です。

というのも中小企業のサイトを踏み台にしてその取引先である大企業の情報を盗み取ろうというのが攻撃者の狙いだからですね。

よって、Webページ管理者だけが被害に遭うものではなく、サイト閲覧者にまで被害が及んだりするものなので、WAFによるセキュリティ対策は被害を広げないために必要不可欠だと言えるのです。

当社でもある企業のメールフォームを利用したところ、その情報が盗み取られてしまったようで、怪しい添付ファイル付きメールが大量に届くようになってしまったことがありました。

5.解決方法

ここからは実際に解決した方法を書き記します。

更新エラーを起こしてしまうのは、WAFが何らかの要因で記事の編集作業をサイトへの攻撃とみなされてしまうのが原因なので、普通のファイアーウォールと同様に除外設定をしてしまえば良いわけです。

WAFの設定はレンタルサーバーに組み込まれているので、基本的にはそのコントロールパネル内で設定を行います。

ですが、当社で使用しているレンタルサーバー(お名前ドットコム)については、以下のような注意書きが記載されています。

どうやらお名前ドットコムでは.htaccessを使用している場合は除外記述ボタンを使用することができないようです。
なので、除外設定は.htaccess内で直接記述をする必要があります。

WordPressを使用されているほとんどの方は.htaccessを使用していると思いますので、特に問題ないと思います。

作業手順としては、FTPソフトを使用してWAFから自分のアクセスを除外する記述を加えた.htaccessをアップロードすればOKとなります。

FTPソフトは何でも良いですが、私はWinSCPという物を使っています。
(以前はFFFTPを使っていましたが、ファイルを大量コピーするとよくエラーするのでこっちに切り替えました)

.htaccessの場所はルートディレクトリ(ご自身のドメイン名のファイルの直下、Wordpress本体が置かれている階層と同じ場所)にあると思います。

.htaccessを見つけたら、一旦自分のパソコンにダウンロードしテキストエディタ(私はNotepad++を使用しています)で下記内容を追加します。
既に何か記述があった場合は、一番下の行に加えるのが良いと思います。

#自分自身のアクセスをWAFから除外
SiteGuard_User_ExcludeSig ip(***.***.***.***)

ご自身のIPアドレスはこちらから調べることが出来ます。
()内の「***.***.***.***」部分に先ほど調べたIPアドレスを置き換えてください。

記述を加えたら上書き保存し、FTPソフトでもう一度同じ場所へアップロード。
上書きしますか？というメッセージが出たらそのまま「はい」を選択します。

アップロード後、更新エラーが出なくなれば問題解決です！

この方法の良いところはIPアドレスで直接指定するので、簡単かつ確実に自分のアクセスのみを除外出来ることと、設定が即時反映されることですが、以下のことに注意が必要です。

このたった二行の記述(一行目はコメントなので実質一行)に辿り着くまで二週間以上もかかってしまいました……。
バグ処理ってホント大変ですね。

6.まとめ

今回の更新エラーがWAFにあったという事実について後日調べてみると、Wordpress5シリーズから新たに加わったブロックエディタ(グーテンベルグ)とWAFはあまり相性が良くないようです。

これまで5.0～5.2までは何も問題がなく記事は投稿できていましたが、5.3にバージョンアップしたとたんこのようなエラーになってしまったことや、同じような更新エラーに遭っている方の多くが5.3を使っているように見受けられたので、5.3固有の不具合なのではないかと思います。

ただ、Wordpress 5.2.5や5.1.2にダウングレードしてもエラーが出ていたことを考慮すると「WAFの監視基準が以前と変わった」というような、他にも何らかの要因があったのかもしれません。

いずれにしても今回の不具合はブロックエディタ自体の仕様に問題がありそうなので、今後Wordpressのバージョンアップによって解消されることに期待したいと思います。

2020年6月8日追記：
WordPressバージョン5.4.1が公開されたのでアップデートをしてみました。
現在、自分自身のアクセスをWAFから除外する記述をコメントアウトして稼働させていますが、今の所更新エラーは出なくなりました。
一時的なものかもしれませんが、もう少し様子を見ていきたいと思います。

では最後までありがとうございました。

Follow me!

@auvix_official