A creative SQL injection

It reminds me of an earlier job; we got a system using barcodes for updating work orders (previously they were handwritten, and then entered by hand into the data processing system). The codes on the work orders were strictly 5-digit numeric only codes at the time. However, when first installed, there were no checks on the codes at the barcode scanners, so all of us had lots of fun scanning tea bags, milk packages and everything else with a barcode on. :-)
 
On the surface this looks like a very creative way to do an SQL injection attack. However, it's a real stretch to assume that the text that is OCR'ed from the picture is ever used in an execution context as SQL program code.

The way those types of attacks work is that you have to exploit some weakness in the input parsing part of the system and get the SQL code injected into something that might be used as SQL program code. Crucial point in this type of attacks is that the format of the input is not defined but can be anything.

In this case I don't see such potential because the input format is very well defined, pictures in certain picture format and I would assume that the OCR'ed text is just stored in a table and it's just "data".
 
kpa said:
On the surface this looks like a very creative way to do an SQL injection attack. However, it's a real stretch to assume that the text that is OCR'ed from the picture is ever used in an execution context as SQL program code.
Click to expand...
That is why you need to use precompiled statements in databases. Because if you do not, then this will work. Note the "'" in the string? If you simply throw this into the database, even if you say that you only want to insert this string, then the process is prone to such escape char attacks. You end up first inserting part of it and then executing the rest of the string.

In case nobody spotted it, that car is owned by little bobby tables.
 
Guess I'm old or something but using completely on the fly created SQL code would be the last thing to come to my mind when developing something like the system here in question.
 
kpa said:
Guess I'm old or something but using completely on the fly created SQL code would be the last thing to come to my mind when developing something like the system here in question.
Click to expand...

Sorry, but that happens way to often. First, you are forced to keep all flexible during design and first implementation. So you don't have time for doing it right, and then you have no time to fix things up because someone had set a deadline.

(Fun) Fact is, im my current place of work, the deadline comes first and only during development you find out what the customer wanted, or needs. Oh, and sometimes you get to the price tag after the delivery. I would not be suprised if these kinds of attack would work. Not at all. But then again, I am a cynical old bastard who has seen too much go wrong.
 
kpa said:
On the surface this looks like a very creative way to do an SQL injection attack. However, it's a real stretch to assume that the text that is OCR'ed from the picture is ever used in an execution context as SQL program code.
Click to expand...

The article points to the fact that it's almost certainly not going to work but it's something developers should be thinking about. There are still idiots out there who build SQL statements on the fly.

The moral of the article is that you should check all data coming into your application, even if it's coming from a device that is part of your product and is supposed to provide a specific format (like a barcode scanner or license plate recognition camera). You should check/sanitise all data that is supposed to be of a certain format even if you've already protected yourself from SQL injection. He lists multiple known issues in real-life systems caused by applications not checking data coming from readers, which, as the data was not actually input by hand, were expected to provide sane input.
 
kpa said:
Guess I'm old or something but using completely on the fly created SQL code would be the last thing to come to my mind when developing something like the system here in question.
Click to expand...
I understand. (I am also old). I come from a mainframe DB2 database environment, and I don't even think there is way to not use precompiled SQL statements. (I can't speak for Linux and Windows DB2; I haven't worked with them.) Nonetheless, there are a ton of PHP/MySQL web frontends that take the input data, concatenate stuff with it to make an SQL statement, and run it. There are tools in PHP to sanitize inputs, but they are not always used, and I believe they are not infallible.
 
The photo is funny, but the implied method is beyond crude.

Unix provides a multitude of ways to shoot yourself in the foot, and using SQL in Common Gateway Interface (CGI) programming is certainly one of them.

However, any competent CGI program is going to validate input data variables. That, for example, is what tainting in perl is all about.

The simple defence against SQL injection for CGI programming is to never show SQL statements to the SQL compiler at run-time. You pre-compile each static SQL statement at the outset, with place-holders for the variables. You then execute the pre-compiled SQL, with the variables plugged into the places where they can only be interpreted as data values. That prevents SQL phrases embedded in the user supplied data, like "drop table", ever being seen by the SQL compiler.
 
You must log in or register to reply here.
Back
Top