水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > CSRF対策は基本?

CSRF対策は基本?

2009年12月12日(土曜日)

CSRF対策は基本?

更新: 2009年12月19日1時55分頃

URL踏むと「こんにちは こんにちは!!」 AmebaなうのCSRF脆弱性で“意図しない投稿”広がる (www.itmedia.co.jp)」だそうで。

コミュニティーサイト構築に詳しい専門家は、「CSRF対策は基本的なところ。Amebaなうが対策していなかったのは意外だ」と話している。

「CSRF対策は基本的なところ」と言われると、発見も対処も容易であるような印象を受けますが、これは少し違和感がありますね。

半年ほど前の話ですが、弊社 (www.b-architects.com)のクライアントが新規のECサイトを立ち上げるにあたって脆弱性診断をしようという話になり、外部の会社に見積もり依頼をしたことがあります。その際、業界では知らない人がいないような大手会社の診断メニューも見せていただきました。

そこで印象的だったのは、標準とされるプランにCSRFの診断が含まれていなかったことです。標準のコースにはXSSSQLインジェクションの診断が含まれますが、CSRFは「アドバンスド」プランの方にしか含まれていませんでした。普通のサイトではXSSやSQLインジェクションといった「基本的な」問題を検査するけれどもCSRFは検査せず、より高度なセキュリティが求められる場合に初めて検査するというプラン構成だということです。

つまり、CSRFへの対策は、大手診断会社の標準コースには含まれないような要素であるわけです。

もっとも、CSRFが標準プランに含まれないのは、これがかなり厄介な問題だからという面もあるでしょう。XSSやSQLインジェクションと比較すると、以下のような問題点があります。

修正ではなく対策が必要

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

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

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

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

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

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

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

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

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

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

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

「基本的」と言われると簡単に対処できそうな印象を受けますが、CSRFは、他の「基本的な」脆弱性と比較すると、発見するのも対応するのも面倒です。実はけっこう厄介ですし、意識的に取り組んで行かなければならない問題だと思うのですよね。

※追記: 対策しなくて良いとか、対策しないのが当然だと言っているわけではありません。むしろ「侮るべからず」ということです。注意してほしいと思うのは、発注側がCSRFへの対策を必要としている場合、要件に明確に含めないと対策が行われない可能性があるということです。

関連する話題: セキュリティ / CSRF

人気のページ

最近の日記

関わった本など

デザイニングWebアクセシビリティ - アクセシブルな設計やコンテンツ制作のアプローチコーディングWebアクセシビリティ - WAI-ARIAで実現するマルチデバイス環境のWebアプリケーション体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践ウェブの仕事力が上がる標準ガイドブック 5 WebプログラミングWeb Site Expert #13Dreamweaver プロフェッショナル・スタイル [CS3対応] (Style for professional)友井町バスターズ (富士見ファンタジア文庫)

その他サイト