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

　　SQL参数与存储过程

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

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

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

　　Parameters集合演示代码如下：

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

　　myCommand.SelectCommand.CommandType = CommandType.StoredProcedure;

　　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;