开发人员对于注入攻击可能有了一些了解，但是实际运用中却很难通过把握一些重要环节和技术对注入攻击进行防范。

本节为读者讲解如何利用ADO 本身的参数对象和存储过程技术防止注入攻击，以达到用户界面输入与原始SQL的分离，使黑客无法拼接SQL语句的目的。

SQL参数与存储过程

SQL参数是开发人员很容易忽视的一个环节，通常直接完成SQL语句，然后传递给数据库执行。这样的写法固然简单，但是也为注入攻击埋下了伏笔。如果要避免注入攻击，就要对SQL语句进行专门的过滤处理，但如果直接使用SQL参数对象就可以省去以上 环节。

SQL中的Parameters集合提供了类型检查和长度验证。如果研发人员使用Parameters集合，输入将被视为文本值进行处理，SQL不会将它视为可执行代码。使用Parameters集合的另一个好处是可以实施类型和长度检查，如果值超出范围将触发异常。这是纵深防范的一个好例子。尽可能地使用存储过程，而且应该通过Parameters集合调用它们。

下面通过几行代码说明如何使用参数集合对象，读者注意@au_id参数将被当作文本值而不是可执行代码。同样，对参数将进行类型和长度检查。在下面的示例中，输入值不能长于11个字符。如果数据不遵守参数所定义的类型或者长度，将出现异常。

Parameters集合演示代码如下：

SqlDataAdapter myCommand = new SqlDataAdapter("AuthorLogin",conn);

myCommand.SelectCommandmandType = CommandTypedProcedure;

SqlParameter parm = myCommand.SelectCommand.Parameters.Add(

"@au_id",SqlDbType.VarChar,11);

parm.Value = Login.Text;

请读者注意，使用存储过程并不一定能防止SQL注入。重要的是在存储过程中使用参数对象。如果不使用参数，存储过程使用未经筛选的输入时，就很容易遭到SQL注入攻击。例如，以下代码片段就存在问题：

SqlDataAdapter myCommand = new SqlDataAdapter("LoginStoredProcedure '" +

Login.Text + "'", conn);

正确的代码片段如下所示：

SqlDataAdapter myCommand = new SqlDataAdapter(

"SELECT au_lname, au_fname FROM Authors WHERE au_id = @au_id",conn);

SqlParameter parm = myCommand.SelectCommand.Parameters.Add("@au_id",

SqlDbType.VarChar,11);

parm.Value = Login.Text;