SQL注入对于那些使用动态的SQL数据库的系统是一个严重的威胁（也就是说，应用系统运行的时候，SQL会被编译）。一个熟知SQL技术的黑客很容易攻击这样防护薄弱的系统，但良好的应用程序设计可以减少风险。不要只是眼于满足纸上谈兵，设计人员就必须仔细考虑如何防护黑客可能对应用系统进行的攻击。此外，数据库管理员必须给软件开发者最小系统的权限。
创建一个测试应用系统
我们创建一个简单的测试应用系统可以帮你更好的理解SQL注入是怎么实现的。这个系统是用SQL Server Northwind数据库。为了简化创建应用系统，Employees表是用来作为的用户表。用户的第一个名字和最后一个在名字都存在Employees表。第一个名字和最后一个名字和实际的应用系统中输入的用户名和密码关联。用户可以登录时使用动态SQL，一个参数化查询或存储过程。
你可以下载SQL语句ValidateUserProc.sql，或者得到应用系统的源代码injectSQL.cs 或者injectSQL.vb。
虽然这个示例应用程序是一个Windows应用程序，这可能是一个Web应用程序，甚至是Java应用程序。采用动态SQL和完全独立于操作系统，数据库厂商，和编写应用程序的编程语言，造成的直接后果就是出现这样的缺陷。
……………………
查看全文请点击下载http://www.51testing.com/html/82/n-141082.html
通过存储过程来预防
存储过程可以在创建的时候被编译，但是这些SQL语句在创建的时候会被冻结住，参考上面的例子
' or 1=1-
利用Stored Proc Login按钮，SQL事件探查器显示实际执行：
exec ValidateUser @FirstName = N''' or 1=1--'，@LastName = N'' Where @FirstName contains the following characters: ' or 1=1- |
当FirstName包含' or 1=1-这样的字符时，无论你输入的@FirstName还是 @LastName，存储过程将始终只有执行在创建时候所定义在存储过程中的SELECT语句。 SQL语句的执行是不会因为输入而改变。此存储过程包含2个输入，都是字符串，不管这些输入字符串包含什么，都会被总是当作字符串。即使一个分号被视为普通的输入字符，而不是SQL语句分隔符。
需要特别声明的是，存储过程本身并不防范SQL注入，也就是说如果存储过程本身使用动态SQL的话它也可以SQL注入。在一个取名为sp_excutesql的存储过程中建立SQL字符串在执行的时候与在应用程序中建立SQL字符串在执行的时候一样易受攻击。有一点需要澄清的是：一个存储过程并不一定是易受SQL注入的攻击和它的取名无关。这完全取决于用户怎样使用它。
以下是SQL事件探查表明在执行时有一个企图绕过身份验证，而使用一个参数化查询：
exec sp_executesql N'select EmployeeID from Employees where FirstName = @FirstName and LastName = @LastName', N'@FirstNamenvarchar(4000),@LastName nvarchar(4000)' , @FirstName = N''' or 1=1--' , @LastName = N'' |
正如你所看到的，一个参数化查询是类似于存储过程，因为它处理的输入作为参数，而不是字符串，可以改变文字的查询字符串。如果您下载并审查代码示例，您将看到的代码，以参数化查询与代码调用一个存储过程是非常相似的。
……………………
查看全文请点击下载：http://www.51testing.com/html/82/n-141082.html
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
