kevin77 (3/19/2009)
The solution to solving SQL Injection attacks is simply for every RDBMS system to flat out not allow inline SQL. Everything must be done with stored procedures and parameters.
Even that's not sufficient. I spent a good couple hours explaining to a fairly experienced web developer why this is vulnerable to injection, regardless of what the procedure does.
Pseudo C# code:
SqlCommand cmd = new SqlCommand();
cmd.CommandText = "Exec SomeProcedure @Param1 = '" + txtSomeValue.ToString() + "', @Param2 = '" + txtSomeOtherValue.ToString() + "';"
cmd.ExecuteNonReader();
And don't forget the nicely parameterised stored procedure that goes and builds up a SQL string with those parameters and EXECs it.
No inline SQL
All stored procedure calls must be properly parameterised
Any dynamic SQL within said procedures must be properly parameterised and must not include values from the front end or from the database.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability