在系列文章（三）中，我们介绍了抵御SQL注入攻击的安全编码技术。并详细介绍了Web应用程序安全编码的三个基本方法，包括：输入验证，规避技术，参数化查询。本文我们将继续介绍其他的方法。

　　另一种策略：使用存储SQL过程

　　你完全有可能无法控制特定Web应用程序的输入验证和控制。在许多情况下，SQL的开发在完成后就不再改变了，而Web应用程序的代码却要经历多个版本。

　　你也许没有通过数据库来控制安全的能力，不过还是有办法的。使用存储过程可以给数据库管理员一些防止SQL注入的方法。例如，在微软的SQL中，创建存储过程是很简单的。在此，不妨使用我们前的的例子：

　　wangzhan.com/comment.asp?msg=ni hao ma

　　我们要创建一个过程，仅期望自己的消息内容是：

　　CREATE PROCEDURE sp_addComment
　　@msg nvarchar(30)
　　AS
　　INSERT INTO comments_table
　　(
　　msg
　　)
　　VALUES
　　(
　　@msg
　　)
　　GO

　　执行时，可以这样做：

　　EXEC sp_addComment @msg = $msg

　　使用这种方法，我们就可以确保不会执行“意外”的查询。如果$msg变量中的值不满足过程的数据类型，就会出现一个错误，但不会产生SQL注入的条件。

　　增强最小化特权

　　最小特权的原则要求：任何一层的Web应用程序所使用的任何账户，都不应当拥有超过其为了执行特定职能而必需的更多特权。例如，许多MySQL的版本都用根特权来运行。这样做的风险很大，因为MySQL实例所运行的任何系统命令，都会以最高等级的许可来运行。其实，在几乎所有情况下，MySQL实例为了完成其工作，仅需要几种特定的许可。

　　同样的原则还可应用于不同的层相互会话的方式。例如，应用程序有可能使用一个SQL用户账户来对数据库进行操作。在很多情况下，我们可以在表甚至在列的水平上将特定的许可指派给这个用户账户，防止其被恶意使用后所导致的损害。

　　如果不允许用户表被Web应用程序服务账户删除，就应当从用户那里移除这些许可。如果不允许服务账户修改特定的表,给其只读许可就完全足够了。

　　让最佳方法珠联璧合

　　除了上述的各种强安全措施，从Web应用程序的每一层中清除不用的代码、函数、库、内置的存储过程以及其它不重要的对象都是很好的方法。这要求深入理解每一层的工作机制，理解每一层需要哪些部分才能运作。然而，清除这些不必要的项目会极大地减少攻击面，从而减少了攻击者可用的工具。

　　SQL注入一直居于其它Web应用程序漏洞之上。但是，通过使用上述多种技术的组合，你就可以阻止SQL注入攻击。记住，安全是一个动态的过程，你必须将安全性集成到系统开发生命周期的每一个步骤中。通过将安全性融合到开发生命周期中，并经常执行测试，你就可以赢得一个更好的企业安全环境。

　　在每一个程序投入使用之前，不妨考虑使用动态的Web应用程序测试，以及人工测试与源代码的检查来确保静态代码的安全性。