Best practice to avoid SQL injection vulnerability in SQL Server - ASP.Net

Question

What is the best practice to avoid SQL injection.

I performed McAfee Secure Check in my application, it shows the problem SQL Injection Blind Vulnerability in SQL Server

and offer below

THE ONLY BEST WAY FOR USING THIS VULNERABILITY - IDENTIFICATION OF THE RECEIVING INPUT FOR EACH FORM A PARAMETER AND DISABLING AN INPUT THAT DOES NOT MEET THAT CRITERIA. The following is an acceptable solution, but it is not optimal. Implement parsing of content on data entry fields, including URL parameters. Remove the following characters from any user or dynamic database entry: (examples in VBScript) '(exclude single quote) input = replace (input, "'", "''") "(double quote) input = replace (input," "", "")) (closing bracket) Input = replace (input, ")", ") ((open parenthesis) input = replace (input," ("," "); (half-colony) input = replace (input, ";", "") - (dash) input = replace (input, "-", "") | (pipe) = replace (input, "|", "") When entering text, it is recommended to add quotes around user input.

If I understand the sentence correctly, I must find all the forms in my application and check it in order to not accept any special characters, such as " ' ( ) *

Is there anything else?

How can I make sure my application is not vulnerable to SQL injection?

Edit

---

Additional 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 do not understand what is the McAfee problem found here. because I use a parameterized stored procedure to log in a user. and user inputs are checked on the client side

Answer 1

This is bad advice. He is painstaking, error-prone and likely to suffer from regression failure. The best approach is only to provide access to data using parameter-based queries.

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

Answer 2

The best practice is to always parameterize your queries; i.e. turn them into something like:

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

How do you do this in C #, for example:

 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 3

In fact, a much safer and more proven way to ensure that you are not honored for SQL injection using your web application is to ensure that your web application does not have permission to execute any dynamic slq.

If you install stored procedures and grant website permissions to execute these stored procedures, you are guaranteed to be safe by providing, of course, that your stored procedures do not do something funky.