views:

104

answers:

6

Possible Duplicate:
XKCD SQL injection - please explain

What is the general concept behind sql injection ?

Being a rails developer

This is unsafe

  Booking.find(:all, :conditions => [ 'bookings.user_id = #{params[user_id]]}'] )

and this is safe:--

 Booking.find(:all, :conditions => [ 'bookings.user_id = ?', params[user_id]] )

am i right?

So my question is how the sql injection is done? How those guys do some stuff like that. Any live example/ tutorial where somebody is showing this kind of stuff. Anything basic for knowing the logic.

+1  A: 

All the user has to do is enter:

1234; DROP TABLE BOOKINGS

...

froadie
A: 

If your data in properly cleaned and sanatized, a user can try to get their own SQL code to run on the server. for example, let's say you have a query like this:

 "SELECT * FROM products WHERE product_type = $type"

where type is unchanged user input from a text field. now, if I were to search for this type:

(DELETE FROM products)

You are gonna be in a world of hurt. This is why it's important to make sure all user input in sanatized before running it in the DB.

GSto
+1  A: 

I don't know about rails, but by doing this Booking.find(:all, :conditions => [ 'bookings.user_id = #{params[user_id]]}'] ), you risk that the user give to user_id the value 1 OR 1=1 and as you can see, it will modify your request.

With more injection you could do something like 1; DROP TABLE BOOKINGS etc.

Basically injection is just "hijacking" a basic request to add yours.

Bobby tables

Colin Hebert
+1  A: 

If you have a simple query like

SELECT * FROM bookings WHERE user_id = ORDER BY user_id ASC;

if you don't check user id, it can close your query, then start a new (harmful one) and discard the rest. To achieve this, generally, you would enter something like

1; DELETE FROM bookings; --

initial ; closes the good query, the bad query comes next, then it is closed with ; and -- makes sure that anything that would come next in the good query is commented out. You then end up with

SELECT * FROM bookings WHERE user_id = 1; DELETE FROM bookings; -- ORDER BY user_id ASC;

Zaki
+1  A: 

SQL Injection happens when a programmer gets lazy. A vulnerable query would look like this:

DECLARE @cmd varchar(256)

SET cmd='SELECT @col FROM Table'
EXEC @cmd

With @col being a variable passed into a stored procedure.

Usually, the user would enter a column in that already exists for that variable. But a more devious user could enter something like this:

* FROM Table; DROP DATABASE data;--

The * FROM Table; finishes off the previous statement. Then, DROP DATABASE data; is the payload that does bad things, in this case, dropping the database. Finally, the -- comments out the rest of the query so it doesn't get any errors from the injection.

So, instead of executing this:

SELECT column
FROM Table

You get this:

SELECT *
FROM Table;
DROP DATABASE data;
--

Which is not good.

And this: alt text

fire.eagle
Voted up for XKCD. Writing out the example from the comic and what exactly happens would be awesome.
npsken
A: 

Plenty of excellent papers on the theory of SQL injection here:

sql injection filetype:pdf

Should be easy enough to hunt one down that is specific to your language/DB combination.

Martin