SQL Injection woes…
I read an article in an IBM DB2 Magazine that has similar info. Looks like something that a lot of developers are going to have to work on fixing.
So I forgot to blog about the SQL Injection problems that I have come across. This certain one used SQL Injection to get into an admin side of a shopping cart website and made some changes to the payment parts and set the money to go to him/her.
The SQL Injection related to logging into a website with forms authentication with a Username and Password box. In Classic ASP you could see something like
set adconn = Server.CreateObject(“ADODB.Connection”)
set adRS = Server.CreateObject(“ADODB.Recordset”)
adconn.Open connectionString
strSQL = “select * from tblUsers WHERE UserId = ‘” & Request.Form(“username”) & “’ and Password=’” & Request.Form(“password”) & “’”
adRS.Open strSQL, adConn
if adRS.EOF Then
‘ not a user authenticated
else
‘ is a user authenticated
end ifSo if I put in the box junior’ or 1 = 1 –
So the statement would look like this: select * from tblUsers where UserId = ‘junior’ or 1=1 – ‘ and Password=’passwordfield’
Being that we used the double – SQL Server will only execute whether the UserId = junior or 1=1, which we all know that 1=1 so there will be a recordset coming back, and therefore it will be counted as authenticated.
Now this was a very simplistic example, and there are many more that are more complex, but it is fairly common to have situations like this where someone can get in and wreak some havoc. So please remember to use the ADODB.Command and ADODB.Parameter so that you do not run into the SQL Injection attacks that you can have with concatenated strings.
