This project is archived and is in readonly mode.
CSRF not working Rails 3.0.7
-
Matthew Daubert
The request_forgery_protection tests pass for me for both 3.0.7 and master branches but I also see the same behavior with your test app. I wonder if the change below could have something to do with it? This was where the InvalidAuthenticityToken exception used to be thrown. I thought that Metal threw this exception and then Dispatch rescued it as an :unprocessable_entity. Looks like this changed at some point to now call reset_session (if the application doesn't overload the handle_unverified_request method).
I'm not sure what's going on but if it's a real issue then there is also a problem with false positives in the test suite.
https://github.com/rails/rails/commit/66ce3843d32e9f2ac3b1da20067af...
-
Matthew Daubert
Looks like this is the expected behavior as of Rails 3.0.4:
http://jasoncodes.com/posts/rails-csrf-vulnerabilityFor the old functionality you can add this to your ApplicationController:
def handle_unverified_request raise(ActionController::InvalidAuthenticityToken) end -
Santiago Pastorino
- State changed from new to invalid
- Importance changed from to Low
Please read http://weblog.rubyonrails.org/2011/2/8/csrf-protection-bypass-in-ru...
Basically you won't get an exception anymore, a session reset will happen now. -
mrbrdo
I see. Can you explain why the exception is not raised anymore? Is there a security issue if you raise an exception as suggested by Matthew Daubert?
Thank you.
-
Santiago Pastorino
Because of API calls.
More info here http://groups.google.com/group/rubyonrails-core/browse_thread/threa... -
Matthew Daubert
mrbrdo - keep in mind that CSRF protection is meant to prevent session hijacking and has nothing to do with authorizing actions within your application. The Security Guide is a great resource but a bit out of date on this topic (I noticed that docrails/master was updated to reflect the change in 3.0.4 so I imagine the guides site will reflect this soon enough).