This is not the problem. Please stop spreading misinformation.
ActiveRecord does escape user input.
The exploit here is that under certain obscure circumstances it is possible trick ActiveRecord into thinking the user input is an options hash passed by the caller.
From my understanding this is non-trivial to exploit on most applications, and requires passing in a Hash with symbol keys.
This is still a vulnerability that needs to be (and has been) fixed, but it is nowhere near as stupidly obvious as you are claiming.
Umm.. I didn't say that ActiveRecord doesn't escape user input. So, stop spreading misinformation about my post ;-)
The fact of the matter is, whether its in some dark edge-case or not, user-provided data is being used to compose a SQL statement that is being passed to the server. Escaped or otherwise, that's a recipe for an injection attack.
> user-provided data is being used to compose a SQL statement that is being passed to the server. Escaped or otherwise, that's a recipe for an injection attack
How do you implement authentication if you can't check an email (user provided data) matches a password (user provided data, probably hashed but still)? How do you look up blog posts by a user-provided tag, without using that tag in query composition? How do you save any user provided information at all without somehow including that information in an SQL query?
You have to use escaped user provided data all the time in a real application. Any actual web developer would know that.
Simple: use parametric prepared statements instead of composing a SQL string with the user-provided data (escaped or otherwise).
This has been available in numerous database APIs for like, ever.
For example [1], [2], [3]. Any actual web developer will have read something along the lines of [4].
A lot people seem confused by my original post, which was in response to a Django user's question about how this sort of thing happens. I provided a general response which seems to have offended some people.
Yes, Rails does appear to use parameterized statements. However, when it is building those parameterized statements it's still using user provided data to build the SQL. If that weren't the case, then this wouldn't be a bug at all, would it? Of course not, so obviously it is using user-provided data in some way, otherwise an HTTP cookie's value wouldn't be getting passed to the database, would it? The prepared statement string shouldn't be composed with anything user provided.
The attack is targeting a secondary method signature that #find_by_* can hold with the express purpose of executing arbitrary SQL. That is, when #find_by_* is invoked with a hash with a key such as :select or :conditions it expects a SQL string, probably hard coded.
The bug however is that it's possible for user input, with a session hijacking, to provide that hash with symbolic key. There is no SQL injection, this is straight up arbitrary execution of SQL.
Out of curiosity, all other debates aside, would it not be helpful to have (either built-in or as a separate plugin) a way for Rails to run a simple set of sanity checks on the SQL it passes to the DB server? For example, checking to make sure that the generated SQL doesn't contain "--" wouldn't fix the underlying problem, but it could be used to prevent the exploit from ultimately working (and, if someone tried this, would alert you to that fact, assuming the error was logged).
I get that this would create some performance overhead, so it would ideally be configurable.
You're the one calling people names. The guy who wrote the fix that was actually accepted by the Rails core team called this a "SQL Injection" and it has been filed in that category by numerous independent bug trackers.
I don't quite understand the angst about this defect being called a SQL injection vulnerability. The vector for the attack doesn't change the end result.
The cause might be that the API was broken, but it doesn't change the fact that a guy wrote SQL code that was injected into the middle of the rest of the SQL generated by the ORM.
ActiveRecord does escape user input.
The exploit here is that under certain obscure circumstances it is possible trick ActiveRecord into thinking the user input is an options hash passed by the caller.
From my understanding this is non-trivial to exploit on most applications, and requires passing in a Hash with symbol keys.
This is still a vulnerability that needs to be (and has been) fixed, but it is nowhere near as stupidly obvious as you are claiming.