# A creative SQL injection



## jrm@ (May 9, 2013)

http://www.circleid.com/posts/20130325_sql_injection_in_the_wild/


----------



## ChalkBored (May 10, 2013)

I laughed when I saw the picture of the car.


----------



## tingo (May 12, 2013)

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.


----------



## kpedersen (May 12, 2013)

Haha, this is great!

I might have to try this out one day


----------



## kpa (May 14, 2013)

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".


----------



## Crivens (May 14, 2013)

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.


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.


----------



## kpa (May 14, 2013)

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.


----------



## Crivens (May 14, 2013)

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.



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.


----------



## Avyd (May 21, 2013)

Awesome, that made my day. That's really creative and that's what hackers need.


----------



## usdmatt (May 21, 2013)

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.



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.


----------

