COLUMN
CMSのセキュリティ対策｜比較表に出てこない運用の話
深夜、サイト監視の設定を保存しようとしたら、419エラーが返ってきたことがある。
CSRFトークンが一致しない、という意味のエラーだ。
ログインし直しても、キャッシュを消しても直らない。
画面には何の変哲もない保存ボタンがあるだけなのに、押すたびに同じエラーが返ってくる。
原因を追ったら、CMSの根っこに近いところに、思っていたより単純な見落としがあった。
CMSのセキュリティ、比較表でよく見る項目
CMSを比較検討するとき、セキュリティの欄にはだいたい同じ項目が並ぶ。
SSL対応、WAF、脆弱性診断の有無、権限管理の細かさ、操作ログの有無。
どれも大事な項目で、丸がいくつ付いているかで選ぶ気持ちはよく分かる。
うちのコンテナも、この手の項目ならひととおり丸が付く。
けれど実際に事故が起きたのは、比較表のどの欄にも書かれていない場所だった。
表に出てこないのは「運用中に起きること」
コンテナには、サイトの死活監視や稼働状況を管理画面から設定できる「サイト監視」という機能がある。
ある時期、この設定を保存しようとすると419エラーで弾かれる、という不具合が起きた。
ブラウザのCookieもログインセッションも正常で、他の画面の保存は問題なく通る。
サイト監視の保存だけが、決まって419で落ちていた。
再現条件を探すのに時間がかかったのは、他の管理画面では一度も起きていなかったからだ。
なぜプラグインのAPIだけセッションが切れていたのか
調べていくと、サイト監視の保存は管理画面本体のルートではなく、プラグイン用のAPI経路を通っていることが分かった。
管理画面本体はセッションを開始したうえでCSRFトークンを検証する前提で作られている。
ところがプラグインのAPI経路は、その前提となるセッション開始の処理を素通りしていた。
検証する側は動いているのに、そもそもセッションが始まっていないので比較のしようがなく、毎回弾かれる、という状態だった。
表面上は「CSRFが効いている」ようにも見えるので、しばらく気づかれずに残っていた。
機能そのものではなく、機能を呼び出す経路の作り方に差があった、というのがこの不具合の正体だった。
直したあとに気づいたこと
修正は、CSRF検証の処理自体をセッションの有無に依存させず、自己完結させる形に直した。
プラグインのAPI経路でもセッションを明示的に開始してから検証するようにしたことで、419は出なくなった。
直してから気づいたのは、この手の不具合は「機能が動くかどうか」のテストだけでは見つからないということだ。
サイト監視という機能そのものは、保存ボタンを押すまでは正常に見える。
壊れていたのは機能ではなく、機能と機能の間をつなぐ認証の経路だった。
似たような作りのプラグインが他にもないか、同じ観点で一つずつ洗い直す作業も、このとき初めてやった。
比較表を見るときに聞いておきたいこと
CMSを比較するとき、「セキュリティ機能がある」ことと「その機能がすべての経路で正しく効いている」ことは、別の話だと思う。
管理画面の主要な操作だけでなく、プラグインや拡張機能の保存・削除・実行が同じ強度で守られているか。
そこまで比較表には出てこないので、気になる機能があれば実際に触らせてもらうか、担当者に直接聞いてみるのが早いのではないだろうか。
うちのコンテナでは、この件をきっかけに認証まわりの処理を洗い直し、プラグイン機構全体でセッションとCSRF検証の扱いを統一した。
今も続けている点検
この一件のあと、新しいプラグインを作るたびに、管理画面本体とは別経路のAPIがないか、あるならセッションとCSRF検証をどう通しているかを確認する項目をチェックリストに加えた。
比較表の丸の数だけでは分からない部分なので、増えた項目はどれも地味で、営業資料の前面には出しにくい。
それでも、419エラーで一度弾かれた記憶がある分、この点検を省く気にはならない。
サイト監視の使い方や設定項目は、サイト監視の機能ページで紹介している。