CSRF対策

CSRFは対策が難しい、というお話。
CSRF対策は基本? | 水無月ばけらのえび日記

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

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

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

発見するのが面倒、うっかり発見されることも少ない、だからいろいろな統計でも数が少ない。
＝ 潜在的にはたくさんありそう、ということらしい。

仮に脆弱性が存在しても、対策が単純でない。

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

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