Potential Circumvention of CSRF Protection in Rails 2.1
Posted by michael November 18, 2008 @ 06:13 PM
There is a bug in all 2.1.x versions of Ruby on Rails which affects the effectiveness of the CSRF protection given by protect_from_forgery.
By design rails does not perform token verification on requests with certain content types not typically generated by browsers. Unfortunately this list also included ‘text/plain’ which can be generated by browsers.
Impact
Requests can be crafted which will circumvent the CSRF protection entirely. Rails does not parse the parameters provided with these requests, but that may not be enough to protect your application.
Affected Versions
- All releases in the 2.1 series
- All 2.2 Pre Releases
Fixes
The upcoming 2.1.3 and 2.2.2 releases will contain a fix for this issue.
Interim Workarounds
Users of 2.1.x releases are advised to insert the following code into a file in config/initializers/
Mime::Type.unverifiable_types.delete(:text)
Users of Edge Rails after 2.2.1, should upgrade to the latest code in 2-2-stable.
The patch for the 2.1.x series is available on github. This will also apply cleanly to 2.2 pre-releases prior to this changeset released on Thursday November 13th at 11:19:53 2008 CET. Users with edge-rails checkouts after that date, are advised to upgrade to the latest code in 2-2-stable.
Thanks to Steve from Coderrr for reporting this issue.
I presume for the blog post that 2.0.x and older versions are not vulnerable? Correct?
Typo: “By design rails DOES NOT DOES NOT perform token verification on requests with certain content types not typically generated by browsers.”
I’m confused. Can’t you set arbitrary Content-Type headers with XmlHttpRequest? Or are Ajax requests somehow generally not usable for CSRF attacks?
@toupeira
Yeah, but then you can’t connect with another server because of the same-origin-policy, so CSRF is not an issue then.
@Van der Hoorn: 2.0 has different logic but is indeed still affected.
@toupeira the interesting thing about CSRF is that it can only be performed via regular form submission. It’s possible to script the form submission, so it happens without user intervention, but the same-origin-policy makes it impossible for an attacker to send your cookies to a remote server through XHR.
Incidentally, as a result, Rails should skip CSRF-checking for XHRs, which would help with the now-notorious problem of needing to set up and include the forgery token in XHR requests.
Hey, shouldn’t you be crediting my friend who told you about this security bug?
@Mathijs, @Yehuda: thanks for your answers, I was actually asking because I implemented request forgery protection in my own little framework and wasn’t sure if it’s actually needed for XHR requests, so I’ve disabled it now.
To be protected by the Rails CSRF protection, you have to make sure, that your dangerous methods can not be called via GET, since it just works with POST etc. For RESTful apps, this should be the case, but be careful with others…
Will there still be a ‘official’ 2.1.3 release?