2007年6月20日(水曜日)
POST にすることは CSRF の対策と言えるのか
「Webアプリケーションを作る前に知るべき10の脆弱性 (www.atmarkit.co.jp)」。いろいろ微妙な感じがするのですが、特に気になったのがこれ。
5．クロスサイトリクエストフォージェリ
CSRF（Cross Site Request Forgery）は、本来拒否すべき外部のWebページからのHTTPリクエストを受け付けてしまうというバグによって起こります。
(～中略～)
ランダムなトークンをフォームやURLに埋め込んでその整合性を確認したり、重要なデータ更新を扱う際には再度認証を行ったり、GETは使用しないといった対策が有効です。
前からずっと思っているのですが、「GETは使用しない」「POSTのみ許可する」というのは CSRF の「対策」になるのでしょうか? CSRF の性質上、POST で攻撃できないという道理がありませんし、実際、私が届け出たものも、「ぼくはまちちゃん」も、いずれも POST で攻撃が成立するものでした。逆に GET で攻撃された例というのは聞いたことがありません。
そもそも、普通は重要なデータ更新を扱う処理を GET にしたりはしないはずです。GET にすると、処理完了画面を利用者がリロードしただけで、データ更新処理がもう一度走ってしまいます。それはまずいですから、機能要件の面から POST にしろという要請があるはずです。
※POST でもリロードできますが、その場合は「データをもう一度送信しますか?」と聞かれるはず。
ちなみにRFC2616 の 9.1.1 にも、こんな事が書いてあります。
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.
POST による攻撃しか見たことがないのは、CSRF 攻撃が成立しそうな部分には元から GET なんか使われていないからでしょう。GET が使われていたらまずいだろうとも思います。
そういったわけで、「重要なデータ更新処理を GET で実行できないようにした方が良い」というのは全くその通りだと思うのです。しかしながら、それが CSRF の「対策」になっているかというと、そんなことはないわけでして。対策として「有効」みたいに言われてしまうと、POST になっていれば CSRF 攻撃を受けないと誤解する人が出てきたりしないか、ちょっと心配です。
- 「POST にすることは CSRF の対策と言えるのか」へのコメント (9件)
- 前(古い): 2007年6月17日(Sunday)のえび日記
- 次(新しい): 2007年6月21日(Thursday)のえび日記
