[Rails] SQL Injection Attacks

Dave Thomas pragdave at gmail.com
Fri Dec 3 15:17:27 GMT 2004


On Dec 2, 2004, at 5:19, David Heinemeier Hansson wrote:

> Bottom line: Please be specific about security concerns. If Rails has 
> a security bug, I'm the first that wants to hear about it. If you have 
> a specific feature that you think would make it easier on you as a 
> developer to deal with security, please write up a proposal (your 
> points for the quoting is almost that) or better yet supply a patch 
> for consideration.

Interesting, I actually posted a bug report on this at the start of the 
week, then withdrew it a couple of hours later. I'm not thinking that I 
should have let it stand.

I see the issue as this. In SQL dialects that allow substitution into 
commands, you are protected against sql injection. If you say

     stmt = db.prepare("select * from people where id=?")
     stmt.execute(@params[p_id"])

it doesn't matter what's in the parameter. You expect an integer, but 
if it contains the string "1; select * from passwords" it won't make a 
difference.

In Rails, the documentation for criteria makes it look as if the same 
is true. It isn't. If I say

    table.find_all([ "id=%d", @params{"p_id"]))

then a malicious incoming string will indeed inject SQL into my system. 
Rails _looks_ as if it gives protection, but in reality as a developer 
you have to take responsibility for your own. You have to know the 
quoting rules for your database, and make sure to take account of them 
in each criteria you use.

I'd very much like to see Rails move towards

   table.find_all([ "id = ?", id] )

and have it use the underlying database to do the substitution.


Cheers

Dave



More information about the Rails mailing list