Article Discussion: SQL Injection Attacks: Are You Safe?

SQL Injection Attacks: Are You Safe? If you have any questions or comments about this article, or if you've had any exposure to SQL injection attacks then please feel free to share your stories here.

You can read the article here .

Hey

If magic_quotes is enabled, some of the SQL injection attacks is prevented. It is pretty much equal to the stripQuotes function in the article.

Of course its by no means close to beeing a foolproof protection.

Wheater one likes magic_quotes or not, it's helping PHP to be safer out of the box.

Emil

This article seems to be slightly incomplete in terms of guarding against attacks where an SQL numerical comparison is being used.

The killchars is a bit of a kludge. A comprehensive approach is:

(i) Any numeric comparison must cleanse user input of *everything* other than numbers, _SINGLE_ decimal point and (optionally) single leading minus sign.

(ii) Any string comparison must put user input between single quotes after replacing all single quotes with a pair.

So (i) requires something like this (just an example, this doesn't check for multiple decimal points etc.):


Private Function myVal(strField)

Dim strTemp,strDigits,char,i

strTemp = "" & strField
strDigits = ""

If Len(strTemp) < 20 Then '/* Guard against maliciously long strings */
For i = 1 To Len(strTemp)
char = Mid(strTemp,i,1)
If char >= "0" And char <="9" Or char = "." Then
strDigits = strDigits & char
End If
Next
End If

If strDigits = "" Or strDigits = "." Then
strDigits = "0"
End If

myVal = strDigits

End Function

Hopefully it would not be offensive if I comment the mistake found on URL

"
select count(*) from users where userName='john' and userPass='' or 1=1 --'

In the example above i've italicised the username and password so they are a bit easier to read, but basically what is happening is that the query now only checks for any user with a username field of john. Instead of checking for a matching password, it now checks for an empty password or the conditional equation of 1=1, meaning that if the password field is empty OR 1 equals 1 (which it does), then a valid row has been found in the users table. Notice how the last quote is commented out with a single-line comment delimiter (--). This stops ASP from spitting an error about any unclosed quotations.

"
This query do not cheks for username field of john: in this condition "1=1" is always true and "or" makes it valid for all usernames and userpass no matter what they are.

I think it says that, just isn't obvious. Yes, since it is using an OR operator, if either condition is true, the result will be true. Therefore, username is ignored totally since 1=1 always.

No, not obvious. It is mistaken because he continues:
"
So with the login.asp script we created above, one row would be returned, and the text "Logged In" would be displayed. "

But "with the login.asp script we created above," all rows would be returned. Anyway, the article is good.

Hmm, it seems there is a method to be injection safe. And still using sql in asp/jsp and co.
Well, I mean safety limited to the safety of the uderlaying database.

Using PreparedStatement (JDBC) or the ADO equivalent of parameterized queries would limit the vulnerability, wouldn't it`?

For example,
select count(*) from users where userName=? and userPass=?

In JDBC, any single quotes would be converted to double quotes and you cannot specify a column in the parameter.

/Fredrik

Some good doc's on SQL attacks and injection, and how to avoid them:

http://www.groar.org/expl/beginner/appt.txt

http://www.sensepost.com/misc/SQLinsertion.htm