Proving SQL Injection

Question

I\'m trying to simply prove here that this simple function isn\'t good enough to prevent every sql injection in the world:

Function CleanForSQL(ByVal input A         


        

Answer 1

You're not doing anything wrong. This is how SQL Server parses strings. The first quote opens the string, then you've followed that immediately with an escaped quote followed by Chr(8).

As an exercise, what happens if you run this in SQL Server: SELECT '''Hello'? Exactly the same parsing rules are being applied in this case.

Answer 2

I think your problem is that Chr(8) is not executed, you need to find another way to get the leading quote mark in.

Answer 3

The Chr(8) is part of the quoted literal string, as is the update statement, so SQL Server is not going to interpret it as a function call. With this example, Text1 will be set to the literal value:

'Chr(8); update tblMaint SET Value1 = 2 WHERE ValueID = 2--

(yes, including that single quote)

So, with this example, your code is secure. Most hang-wringing over SQL injection is about accidentally failing to validate and quote values, there is nothing inherently unsafe in a properly-quoted SQL statement.

Answer 4

Scott Ivey has the classic case that can break it, the lack of quotes protecting a numeric input. (+1'ed that)

Depending on the language and where the string is being 'cleansed' and the database being used your immediate risk is that they language permits the string to be escaped. At that point the single quote you are trying to avoid getting thru goes wrong

\'; DROP yourTable;-- => \''; DROP yourTable;--

That goes into your sql string as

UPDATE tblFilledForms SET Text1 = '" + \''; DROP yourTable;-- + ' etc.

Which is then:

UPDATE tblFilledForms SET Text1 = '\''; DROP yourTable;-- ' etc.

'\'' is taken as the literal string of a single quote, if your database supports escaped characters - bingo your compromised.

Equally the protection has to be remembered to be effective, even the example update statement provided failed to protect the parameter in the where clause, was it because DGVNotes.SelectedRows(0).Cells("FilledFormID").Value.ToString) could never be entered by a user? will that hold true for the entire lifetime of the app etc?

Answer 5

Your CleanForSQL method only handles string situations. What happens when you're not using a string but an INT instead? In that case, there would be no end tick to close with, so the injection would still happen. Consider this example...

Database.DBUpdate("UPDATE tblFilledForms SET Int1 = " + CleanForSQL(txtNote.Text) + " WHERE FilledFormID = " + DGVNotes.SelectedRows(0).Cells("FilledFormID").Value.ToString)

in that case, just entering the following will work...

0; update tblMaint SET Value1 = 2 WHERE ValueID = 2--