Your code is vulnerable to SQL injection attacks wherever it uses input parameters to construct SQL statements. As with XSS bugs , SQL injection attacks are caused by placing too much trust in user input and not validating that the input is correct and well- formed .
The following process helps you locate SQL injection vulnerabilities:
Look for code that accesses the database.
Scan for the strings "SqlCommand," "OleDbCommand," or "OdbcCommand."
Check whether the code uses parameterized stored procedures.
Stored procedures alone cannot prevent SQL injection attacks. Check that your code uses parameterized stored procedures. Check that your code uses typed parameter objects such as SqlParameter , OleDbParameter , or OdbcParameter . The following example shows the use of a SqlParameter :
SqlDataAdapter myCommand = new SqlDataAdapter("spLogin", conn); myCommand.SelectCommand.CommandType = CommandType.StoredProcedure; SqlParameter parm = myCommand.SelectCommand.Parameters.Add( "@userName", SqlDbType.VarChar,12); parm.Value=txtUid.Text;
The typed SQL parameter checks the type and length of the input and ensures that the userName input value is treated as a literal value and not as executable code in the database.
Check that your code uses parameters in SQL statements.
If you do not use stored procedures, check that your code uses parameters in the SQL statements it constructs, as shown in the following example:
select status from Users where UserName=@userName
Check that the following approach is not used, where the input is used directly to construct the executable SQL statement using string concatenation:
string sql = "select status from Users where UserName='" + txtUserName.Text + "'";
Check whether or not your code attempts to filter input.
A common approach is to develop filter routines to add escape characters to characters that have special meaning to SQL. This is an unsafe approach, and you should not rely on it because of character representation issues.