[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