Question

Suppose I’ve got a search box on a page in a Rails 3 app where you can search for a client by business name or city. In my controller’s index method I do this:

if params[:search]
  @clients = Client.where("clients.business_name LIKE :business_name OR clients.city = :city", :business_name => "%#{params[:search]}%", :city => params[:search])

Those hash values get substituted into the SQL and surrounded in quotes. If my input into the search box includes quotes or other dangerous characters, I’ll see them being escaped in the development log, like:

…WHERE (clients.business_name LIKE ‘%Something\’ DROP TABLE Foo%’…

Or

...WHERE... OR clients.city = 'Something OR 1=1')

So, since the OR 1=1 is inside the quotes Rails adds, it just produces no match for the city name, and since the quote in the DROP TABLE attempt is escaped, it also produces no match for the business name.

This isn’t using actual prepared statements, where the query is sent to the database first without the search values filled in, then subsequently, the search values are sent to the database to fill in. I thought that was the safest approach, but Rails doesn’t do it; I think this is because it’s not available in all databases and implementations vary.

Is this open to SQL injection in some way? I don’t see it, but again, it’s not using prepared statements, so I wonder. If there’s a vulnerability, how could I do this more safely?

Answer 1

No, there’s not a SQL injection vulnerability here. ActiveRecord will call connection.quote on the values of the hash that you passed in as the second parameter to where, so you are safe.

The only potential SQL injection point I could think of would be if there were some undiscovered bug in connection.quote, which is pretty unlikely.