Best practice to avoid Blind SQL Injection Vulnerability in SQL Server - ASP.Net

Question

what is the best practice to avoid SQL injections.

I have ran a McAfee Secure Check on my application, it shows a problem Blind SQL Injection Vulnerability in SQL Server

and the suggestion is as below

THE SINGLE BEST WAY TO FIX THIS VULNERABILITY IS TO IDENTIFY THE ACCEPTABLE INPUT FOR EACH FORM PARAMETER AND REJECT INPUT THAT DOES NOT MEET THAT CRITERIA. The following is an acceptable solution however it is not optimal. Implement content parsing on data input fields including URL parameters. Remove the following characters from any user or dynamic database input: (examples in VBScript) ' (escape the single quote) input = replace( input, "'", "''" ) " (double quote) input = replace( input, """", "" ) ) (close parenthesis) input = replace( input, ")", "" ) ( (open parenthesis) input = replace( input, "(", "" ) ; (semi-colon) input = replace( input, ";", "" ) - (dash) input = replace( input, "-", "" ) | (pipe) input = replace( input, "|", "" ) On text input it is recommended to append quotes around the user supplied input.

If i understand the suggestion correctly, i have to find all the forms in my application and validate it for not accepting any special characters like " ' ( ) *

Is there anything more to this?

How can i make sure my application is not Vulnerable for SQL injections

Edit

---

More Specification:

    Protocol https Port 443 Read Timeout30000Method POST
Path /Login
Hea
ders
Referer=https%3A%2F%2Fwww.mydomain.org%2FLogin
Content-Type=application%2Fx-www-form-urlencoded
Body
ctl00_ScriptManager1_HiddenField=0
__EVENTTARGET=0
__EVENTARGUMENT=0
__VIEWSTATE=/wEPDwUJNjc2MTk0ODk1D2QWAmYPZBYCAgMPZBYCAgsPZBYCAgUPFgIeBFRleHQ
FNzxhIGhyZWY9Jy9SZWdpc3RyYXRpb24nIGNsYXNzPSdidXR0b24nPlJlZ2lzdGVyIE5vdzwvYT5kZEMqo
HfESjF9a2aAo6EwUZFLyVY43k2Ywc5HOrQBdZqz
__EVENTVALIDATION=/wEWCgLkzYaLDgKV/vKYDgKBuZWrDQKS/tSgCgLJloD/DALrw4jECgKb/IYvAu2
GxZoEAuemgo8LAoyWmLsKGesm2g0zKeoodCDHz6Mm9GhhkuncAqXhHTAcUjL1R1Y=
ctl00$header1$btnDisclaimerHTMLOK=OK
ctl00$header1$btnDisclaimerHTMLCancel=Cancel
ctl00$header1$btnSubmit=Register
ctl00$cc1$txtEmail=x' wAiTfOr dELay '0:0:20'--
ctl00$cc1$txtPassword=0
ctl00$cc1$cmdLogin=Log In
Protocol https Port 443 Read Timeout30000Method POST
Path /login/
Hea
ders
Referer=https%3A%2F%2Fwww.mydomain.org%2Flogin%2F
Content-Type=application%2Fx-www-form-urlencoded
Body
ctl00_ScriptManager1_HiddenField=0
__EVENTTARGET=0
__EVENTARGUMENT=0
__VIEWSTATE=/wEPDwUJNjc2MTk0ODk1D2QWAmYPZBYCAgMPZBYCAgsPZBYCAgUPFgIeBFRleHQ
FNzxhIGhyZWY9Jy9SZWdpc3RyYXRpb24nIGNsYXNzPSdidXR0b24nPlJlZ2lzdGVyIE5vdzwvYT5kZEMqo
HfESjF9a2aAo6EwUZFLyVY43k2Ywc5HOrQBdZqz
__EVENTVALIDATION=/wEWCgLkzYaLDgKV/vKYDgKBuZWrDQKS/tSgCgLJloD/DALrw4jECgKb/IYvAu2
GxZoEAuemgo8LAoyWmLsKGesm2g0zKeoodCDHz6Mm9GhhkuncAqXhHTAcUjL1R1Y=
ctl00$header1$btnDisclaimerHTMLOK=OK
ctl00$header1$btnDisclaimerHTMLCancel=Cancel
ctl00$header1$btnSubmit=Register
ctl00$cc1$txtEmail=x' wAiTfOr dELay '0:0:20'--
ctl00$cc1$txtPassword=0
ctl00$cc1$cmdLogin=Log In

I don't understand what is the issue McAfee found here. because for user login I am using parameterized stored procedure. and user inputs are validate on client side

Answer 1

The best practice is to always parametrise your queries; that is, transform them into something like:

update your_table 
set cola=@param1, 
colb =@param2

The way you do this on C# for example, is:

using ( ...)
{
  comm = new  SqlCommand("update your_table set cola=@param1, colb=@param2",conn);
  comm.Parameters.AddWithValue("@param1",someValue);
  comm.Parameters.AddWithValue("@param2",someOtherValue);
  comm.ExecuteNonQuery();
} 

Answer 2

That is bad advice. It is painstaking, error prone, and likely to suffer from regression failure. The best approach is to only allow data access via paremeterized queries.

Then, regardless of the user input, you are not vulnerable to SQL injection.

Answer 3

Actually a much more secure and auditable way to insure that your are not venerable to sql injection attacks via your web application is to insure that your web application does not have permission to execute any dynamic slq.

If you setup stored procedures, and only give your website rights to execute those stored procedures, you are virtually guaranteed to be safe, providing of course that your stored procedures don't do something funky.