水無月ばけらのえび日記

修正ではなく対策が必要

XSSやSQLインジェクションなどは単純なバグが原因で発生するものです。指摘された場合、修正の方法について議論する必要もなく、ただバグを修正すれば良いだけです (たまに、変な修正の仕方をする人もいますが……)。

それに対し、CSRFはバグが原因ではありません。設計段階から意識的にCSRFに対応する必要があり、それが抜けていたのであれば設計から再検討する必要があります。また、対策方法もいろいろあるので、どう対策して良いのかすぐには方針が決められない場合があります。

※個人的には、フレームワークにCSRF対策の機能があればそれを使用し、無ければ「高木方式 (takagi-hiromitsu.jp)」で良いとは思うのですが……。

対策が必要かどうか判断が必要

XSSやSQLインジェクションなどは、サイトのどこにあっても危険です。例外もないわけではありませんが、特殊な場合だけでしょう (たとえば、phpMyAdminのようなアプリケーションでは管理者が任意のSQLを実行できるようになっている必要があります)。ほぼ一律に脆弱性とみなせますし、一律で対応すれば良いことになります。

しかしCSRFについては、そもそもそれが脆弱性なのかどうかを判断する必要があります。第三者の用意したフォームからPOSTできるとしても、それだけでは脆弱性とはみなせません。以下のような点を考慮して検討する必要があります。

• 副作用が生じるのかどうか。副作用がない(サーバ側の状態を一切変更しない)場合は問題ありません。たとえば、検索結果を表示したり、確認画面を表示したりするだけの動作であれば問題ないということになります。
• 発生する副作用が有害なものであるかどうか。たとえば、買い物かごに商品を追加する機能がCSRFで攻撃されても、決済が完了できなければ問題ないという考え方もあり得るでしょう (次に利用者が決済しようとしたときに気付くため、被害につながらない)。

発見するのが面倒

一般的なXSSやSQLインジェクションについては、特定の文字をフォームやURLに入れるだけで発見したり、存在を推定したりすることが可能です。そのため、「うっかり」発見されて届け出られるケースも多くなります。

それに対して、CSRFを発見するのはけっこう面倒です。ログインした後でフォームを利用してみてパラメータを見たり、パラメータを変更した状態でPOSTしてみて動作を見る必要があります。しかも、フォームのPOSTでどのような副作用が生じるのか、外部からは簡単に判断できない場合もあります。

脆弱性であるかどうかについては前述のような判断も必要になりますので、機械的なチェックが難しいという問題もあるでしょう。

※余談ですが、情報セキュリティ早期警戒パートナーシップの統計ではCSRFの届出はかなり少ないようで、もはや「その他」扱いです。これは対策が進んでいるためではなく、単に「うっかり」発見されるケースが希だからなのではないかと思います。CSRFの発見にはログインが必要な上に、確認が実に面倒です。私もCSRFの届出は数件しかしていませんが、これは「うっかり」発見する確率が低いだけだと思います。