Blogロードバイク通勤のRubyプログラマで伊豆ダイバー。Forgeries:CSRF)」と言うらしい。手法自体は昔拙著でも書いていて、当時はそんな言葉なかったので「自動投稿攻撃」などとセンスのない名称で言ってたやつです。横文字だとなんか難しげでカッコイイね。そもそもこの脆弱性って、CGIライブラリやWebアプリケーションフレームワークの多く(Strutsにしても、PerlのCGI.pmにしてもPHPにしても)がGETとPOSTの違いを隠蔽して同等に扱えちゃうのが根源だと思うけど...。第一の対策はPOSTメソッドのみ受け付けるようにすること。GETとPOSTの使い分けなんて、どんなサイトでも必須であって、やってないのは問題外(やってなかったのかよmixi)。これだとJavaScriptを使ってPOSTメソッドを生成されてしまうケースがあるので完全ではない。Refererを出力しないブラウザも存在する」(中村氏)ため、前述した方法が推奨されるということだ。(ITmedia)理想的にはその通り。確かに一部のブラウザではRefererは出力されなかったり、プロキシによってカットされちゃうケースもある。CSRFは外部からの攻撃ではなく、自分でリンクを踏んで攻撃しちゃうってやつなので、実質的にはRefererチェックだけでも十分効果あると思っています。「Refererヘッダが来ている場合だけ」チェックすること。しないと一部の環境から機能が使えない状態になってしまう。GETメソッドを弾くのは必須。効果的な対策法であるワンタイムトークンは、CSRFの防御のみならず、遷移制御やSubmitボタン連打防止にも役に立つので、ライブラリとして持っておいたほうが何かと便利だと思われます。理想的にはワンタイムトークンをプログラマがほとんど無意識で使えるような仕組みがフレームワーク的に整っていれば、CSRF脆弱性に対しても、不正な遷移に対しても自然に防御できるようになると思われます。いったことを考えたセキュアなWebアプリフレームワークが欲しいです。超重要な処理では、究極は再認証(パスワード再入力など)です。Yahoo!とかでもやってますね。利便性を損ねることになるので、使うべきところをきちんと考える必要があります。はてなブログProロードバイク通勤のRubyプログラマで、伊豆ダイバー。Founderビットアーツは1998年よりWebアプリケーションを専門としてシステム開発サービスを提供しています。OEM向け製品開発にも取り組んでいます。Webメディア構築クラウド「Clipkit」を開発。東証一部(東証プライム)上場企業へのM&Aを経験しました。9はてなブログをはじめよう!miyamaeさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。