水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > POST にすることは CSRF の対策と言えるのか

POST にすることは CSRF の対策と言えるのか

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.

以上、RFC2616 9.1.1 Safe Methods より

POST による攻撃しか見たことがないのは、CSRF 攻撃が成立しそうな部分には元から GET なんか使われていないからでしょう。GET が使われていたらまずいだろうとも思います。

そういったわけで、「重要なデータ更新処理を GET で実行できないようにした方が良い」というのは全くその通りだと思うのです。しかしながら、それが CSRF の「対策」になっているかというと、そんなことはないわけでして。対策として「有効」みたいに言われてしまうと、POST になっていれば CSRF 攻撃を受けないと誤解する人が出てきたりしないか、ちょっと心配です。

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

最近の日記

関わった本など

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

その他サイト