In the http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3221 entry, what we meant is that CVE-2013-3221 is exclusively about the behavior of Ruby on Rails as discussed in the listed MLIST:[rubyonrails-security] 20130207 reference. If a reference is about a data-type injection impact in an application other than a Ruby on Rails application, it should not be mapped to this CVE. However, an applicable reference about interaction between Ruby on Rails and Microsoft SQL Server (or interaction between Ruby on Rails and IBM DB2) should be mapped to this CVE. (There might be a misinterpretation that CVE-2013-3221 is only about interaction with MySQL. http://twitter.com/dakull/statuses/326633931636084736 possibly suggests that, but we're bringing this up mostly because of a comment that someone else sent directly to MITRE.) Common patterns used in Ruby on Rails applications could allow an attacker to generate SQL that, when combined with some database server's typecasting code, generates queries that match incorrect records. Note: This is a code and best-practise advisory, there is no patch to apply or updated version to install. Databases Affected: MySQL, SQLServer and some configurations of DB2 Not affected: SQLite, PostgreSQL, Oracle Outline - ------- When comparing two values of differing types most databases will either generate an error or return 'false'. Other databases will attempt to convert those values to a common type to enable comparison. For example in MySQL comparing a string with an integer will cast the string into an integer. Given that any string which isn't an invalid integer will convert to 0, this could allow an attacker to bypass certain queries. If your application has XML or JSON parameter parsing enabled, an attacker will be able to generate queries like this unless you take care to typecast your input values. For example: User.where(:login_token=>params[:token]).first Could be made to generate the query: SELECT * FROM `users` WHERE `login_token` = 0 LIMIT 1; Which will match the first value which doesn't contain a valid integer. This vulnerability affects multiple programming languages, and multiple databases, be sure to audit your other applications to see if they suffer the same issues. Work Arounds - ------------ There are two options to avoid these problems. The first is to disable JSON and XML parameter parsing. Depending on the version of rails you use you will have to place one of the following snippets in an application initializer Rails 3.2, 3.1 and 3.0: ActionDispatch::ParamsParser::DEFAULT_PARSERS.delete(Mime::XML) ActionDispatch::ParamsParser::DEFAULT_PARSERS.delete(Mime::JSON) Rails 2.3: ActionController::Base.param_parsers.delete(Mime::XML) ActionController::Base.param_parsers.delete(Mime::JSON) If your application relies on accepting these formats you will have to take care to explicitly convert parameters to their intended types. For example: User.where(:login_token=>params[:token].to_s) Fixes - ----- Unfortunately it is not possible for ActiveRecord to automatically protect against all instances of this attack due to the API we expose. For example: User.where("login_token = ? AND expires_at > ?", params[:token], Time.now) Without parsing the SQL fragments it is not possible to determine what type params[:token] should be cast to. Future releases of Rails will contain changes to mitigate the risk of this class of vulnerability, however as long as this feature is still supported this risk will remain. Credits - ------- Thanks to joernchen of Phenoelit for reporting this to us and to Jonathan Rudenberg for helping to review the advisory. - -- Cheers, Koz