三、典型的SQL安全防护
到现在为止我们已经看到在应用程序中开始一个SQL注入攻击并成功使用它是多么的容易。幸运的是，在上面已经提及过，SQL注入攻击很容易使用一些简单的手段防御。大多数有效的防御方法是在执行SQL语句之前验证应用程序中所有的被使用于数据访问的输入语句。我们可以在Web应用程序中直接来验证，也可以使用一些数据持久化组件，如Hibernate进行验证，当然，不管使用哪种方式，这种验证都需要在处理数据之前在服务端来验证类型、长度、格式和范围。但不幸的是，基于代码的验证方法并不十分简单，当遇到如下三种情况时，还会失败：
1. 验证程序设计不完善。
到现在为止我们已经看到在应用程序中开始一个SQL注入攻击并成功使用它是多么的容易。幸运的是，在上面已经提及过，SQL注入攻击很容易使用一些简单的手段防御。大多数有效的防御方法是在执行SQL语句之前验证应用程序中所有的被使用于数据访问的输入语句。我们可以在Web应用程序中直接来验证，也可以使用一些数据持久化组件，如Hibernate进行验证，当然，不管使用哪种方式，这种验证都需要在处理数据之前在服务端来验证类型、长度、格式和范围。但不幸的是，基于代码的验证方法并不十分简单，当遇到如下三种情况时，还会失败：
1. 验证程序设计不完善。
2. 验证只在客户端执行。
3. 验证失败，即使在应用程序中只有一个单独的字段。
还有别外一种防止SQL注入攻击的方法，就是在应用程序中参数化所有的SQL查询，无论是动态的SQL表达式，或存储过程。如果写出象下面的代码应该是很安全的：
SELECT [CustomerID], [CompanyName], [ContactName]
还有别外一种防止SQL注入攻击的方法，就是在应用程序中参数化所有的SQL查询，无论是动态的SQL表达式，或存储过程。如果写出象下面的代码应该是很安全的：
SELECT [CustomerID], [CompanyName], [ContactName]
FROM [Customers]
WHERE CompanyName = @CompanyName参数化的查询当执行SQL表达式时将输入看到是一个字符串值；因此，将这个值作为可执行的代码是不可能的。即使我们使用存储过程，也必须使用参数化输入，这是因为存储过程并不提供使内嵌查询防止SQL注入的功能。
即便使用上述简单的防护措施，SQL注入仍然会成为许多组织的大问题。对于我们的开发团队来说，最大的挑战就是对所有的开发人员进行防御这种攻击的培训。甚至需要将这些标准和规范装订成册，以供开发人员随时查阅。而且这种方式为了使程序更安全，引入了很多的变量，这样可能会给我们带来更多的工作量。这就需要出现一种更方便和强大的防止SQL注入攻击的技术出现，这就是LINQ的由来。
