読者です 読者をやめる 読者になる 読者になる

Rails3.2系でのCSRFの挙動に気をつける

Rails プログラミング


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