Comments on: Reflected SQL injection

By: Gwyn Fisher

Gwyn Fisher — Tue, 24 Jul 2007 12:43:10 +0000

It’s worth noting that prevalent source code analysis tools (such as the one I represent, Klocwork, full disclosure and all that) can find such reflections as well as the more normal scenarios spelled out above. The tools do tend to be pricey, although there are some very capable open source options available to individual developers that are worth checking out.

Anyway, congratulations on isolating your problem. So many developers let things like this make it all the way through QA and out into the wild, it’s just not funny.

If you’ve got some time, check out our website for description of the kinds of things we find, or go to wikipedia and check out the prevalent open and commercial tools by looking for “static analysis”.

By: Gareth Heyes

Gareth Heyes — Tue, 24 Jul 2007 12:33:15 +0000

It wasn’t as easy as that, the data wasn’t being mirrored but created based on certain conditions.

The idea was to enable a user to choose a set template of data which can be modified dynamically or overwritten when in the new table.

By: ce

ce — Tue, 24 Jul 2007 12:12:21 +0000

when moving from table to table, why don’t just use
INSERT INTO … SELECT … FROM …

By: dancaragea

dancaragea — Tue, 24 Jul 2007 10:16:26 +0000

There are 6 different situations where you have to escape the data in a web app:
(GPC means user data from a form)
1. GPC -> DB (that’s a classic)

2. GPC -> GPC (when there’s an error processing the form and you present the form back, with the form fields pre-filled with whatever data the user entered the first time)

3. GPC -> display (when you write back a message like “you entered ”. This is not the same with gpc->gpc)

4. DB -> GPC (edit forms)

5. DB -> display (e.g. to display blog posts, comments, etc)

6. DB -> DB (rare but you still have to escape this one. I use this case in an application to move messages from a queue table to the inbox table)

By: Felix Zaslavskiy

Felix Zaslavskiy — Tue, 24 Jul 2007 04:08:01 +0000

You should escape your input at the level of the query for example a simple enough wrapper around the query function should do. It would work something like this:

sql_query( “select .. from .. where id=%d”, $id );

This function would do a mysql_escape_string() call on each parameter before doing a sprintf() on the string.

So yes you will be doing extra computations because everything will get escaped but you get worthy security.

By: Gareth Heyes

Gareth Heyes — Mon, 23 Jul 2007 21:54:56 +0000

I had a step by step wizard which asked for the required steps and the code worked for data supplied from the user but it didn’t have any escaping code for data interaction. It does now though

By: Richard Davey

Richard Davey — Mon, 23 Jul 2007 21:45:25 +0000

I’m curious - you escaped the user input before storing it in Table 1 according to your diagram. How was the data then un-escaped in-between making its way from Table 1 to 2?

By: Gareth Heyes

Gareth Heyes — Mon, 23 Jul 2007 15:33:15 +0000

Yep prepared statements would be better I must admit. But the system I had developed wasn’t using them at the time.

I had to store copies of the same data in separate tables because users can either keep the data as it is or modify it to suit their needs.

I could explain further but I’d have to give you more details how the system works, what it does etc.

I just found the vulnerability interesting because my filters didn’t work.

By: Giorgio Maone

Giorgio Maone — Mon, 23 Jul 2007 15:26:42 +0000

Just another crystal clear case supporting prepared statements / parameters binding.

Security aside, using a prepared statement should be your first choice in a loop: why would you want to parse the same SQL source over and over again?