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.
 
You must log in or register to reply here.
Back
Top