CSRFとは，Cross site request forgeriesの略で，入力フォームなどで，外部からPOSTできてしまうという脆弱性を点いた攻撃です．
Rails2.0以降，Railsの生成するフォームでは自動的にCSRFトークンが含まれており，POSTに関しては自動的にCSRF対策がなされている．
ただし，このCSRFにひっかかった際の挙動が問題だ．
基本的に自前のアプリケーション内で，同じアプリケーションのコントローラーにPOSTしている限り，CSRFがどういう挙動をしているか意識する機会は少ない．
ただ，CSRFにひっかかった時にどうなるのかは知っておく必要がある．
特に，Rails3.2系では，CSRFの挙動が他と異なる．
この辺が参考になろうかと思うソースです．
http://qiita.com/naoty_k/items/ce037ea79bb5893f2b89
これは，2.x系とも動作が異なり，Rails4.x系とも異なる．
Rails3.2では，CSRFにひっかかる（つまりCSRFトークンの値が一致しない）場合には，reset_sessionをかけるだけであり，createメソッド内の処理は実行されてしまう．
そのアクションでsessionを見たりする必要がなければ，スルーしてcreateされる可能性がある．
ちなみにこの挙動，Rails4.0だとしっかりエラーが出て，createできない．
3.2の場合は，よくよくログを見ていると，WARNINGまでは出ているのもの，その後の処理は特にエラーなく実行されているので，気づかないうちにCSRFが意味をなしていない可能性があるのだ．
ちなみに，ログインフォーム等のように，sessionをしっかり見なければならないような機能を実装している場合は，reset_sessionであっても問題なさそうですね．
ただそれ以外のフォームの場合は，どういう動作になるのかよく確認した方がいいです．
[参考]
http://blog.champierre.com/962
