Rails Ruby on Rails

Comments and changes to this ticket

• You flagged this item as spam.
  

  Matthew Daubert April 25th, 2011 @ 04:39 PM

  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...

• You flagged this item as spam.
  

  Matthew Daubert April 25th, 2011 @ 04:49 PM

  Looks like this is the expected behavior as of Rails 3.0.4:
  http://jasoncodes.com/posts/rails-csrf-vulnerability

  For the old functionality you can add this to your ApplicationController:

  def handle_unverified_request
    raise(ActionController::InvalidAuthenticityToken)
  end
  

• 

  Santiago Pastorino April 25th, 2011 @ 05:00 PM

  • 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.

• You flagged this item as spam.
  

  mrbrdo April 25th, 2011 @ 05:38 PM

  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 April 25th, 2011 @ 05:50 PM

  Because of API calls.
  More info here http://groups.google.com/group/rubyonrails-core/browse_thread/threa...

• You flagged this item as spam.
  

  Matthew Daubert April 25th, 2011 @ 06:15 PM

  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).