SQL Server 2005 联机丛书
SQL Injection 是一种攻击方法,它可以将恶意代码插入到以后将传递给 SQL Server 供分析和执行的字符串中。任何构成 SQL 语句的过程都应进行注入漏洞检查,因为 SQL Server 将执行其接收到的所有语法有效的查询。
SQL Injection 的主要形式包括直接将代码插入与 SQL 命令串联并执行的用户输入变量。一种间接的攻击会将恶意代码注入要在表中存储或作为元数据存储的字符串。在存储的字符串随后串连到一个动态 SQL 命令中时,将执行该恶意代码。
基本的攻击是提前终止文本字符串,然后追加一个新的命令。由于插入的命令可能在执行前追加其他字符串,因此攻击者将用注释标记“--”来中止注入的字符串。执行时,此后的文本将被忽略。
以下脚本阐释了一个简单的 SQL Injection 攻击。此脚本通过串联硬编码字符串和用户输入的字符串而生成一个 SQL 查询。
复制代码
var Shipcity;
ShipCity = Request.form ("ShipCity");
var sql = "select * from OrdersTable where ShipCity = '" + ShipCity + "'";
用户将被提示输入一个城市名称。如果用户输入 Redmond,则查询将由以下这样的脚本组成:
复制代码
select * from OrdersTable where ShipCity = 'Redmond'
如果用户输入如下内容会怎样呢?
Redmond'; drop table OrdersTable--
此时,查询将由如下所示的脚本组成:
复制代码
select * from OrdersTable where ShipCity = 'Redmond';drop table OrdersTable--'
“;”字符表示一个查询的结束和另一个查询的开始。“--”字符序列则表示当前行余下的部分是一个注释,应该忽略。如果更改后的代码语法正确 ,则服务器将执行该代码。SQL Server 在处理此语句时,将首先选择 OrdersTable 中的所有记录(其中 ShipCity 为 Redmond),然后删除 OrdersTable。
只要注入的 SQL 代码语法正确,就无法用编程方式来检测篡改。因此,必须验证所有用户输入,并仔细检查在服务器中执行构造 SQL 命令的代码。下面讨论了一些编写代码的最佳做法。
验证所有输入
始终通过测试类型、长度、格式和范围来验证用户输入。实现对恶意输入的预防时,请注意应用程序的体系结构和部署方案。请记住,为在安全环境下运行而设计的程序可能被复制到不安全的环境中。以下建议应被视为最佳做法:
· 对应用程序接收的数据不做任何有关大小、类型或内容的假设。例如,评估以下内容:
· 如果是一个用户在需要邮政编码的位置无意中或恶意地输入了一个 10 MB 的 MPEG 文件,应用程序会做出什么反应?
· 如果在文本字段中嵌入了一个 DROP TABLE 语句,应用程序会做出什么反应?
· 测试输入的大小和数据类型,强制执行适当的限制。这有助于防止有意造成的缓冲区溢出。
· 测试字符串变量的内容,只接受所需的值。拒绝包含二进制数据、转义序列和注释字符的输入内容。这有助于防止脚本注入,防止某些缓冲区溢出攻击。
· 使用 XML 文档时,根据数据的架构对输入的所有数据进行验证。
· 绝不直接使用用户输入内容来生成 Transact-SQL 语句。
· 使用存储过程来验证用户输入。
· 在多层环境中,所有数据都应该在验证之后才允许进入可信区域。未通过验证的数据应被拒绝,并向前一层返回一个错误。
· 实现多层验证。对无目的的恶意用户采取的预防措施可能对专业黑客无效。最佳做法是在用户界面验证输入,然后在所有跨信任边界的后续点上验证输入。
例如,在客户端应用程序中验证数据可以防止简单的脚本注入;但是,如果下一层假设其输入已被验证,则任何可以跳过客户端的黑客就可能不受限制地访问系统。
· 绝不串联未验证的用户输入。字符串串联是脚本注入的主要输入点。
· 在可能据以构造文件名的字段中,不接受下列字符串:AUX、CLOCK$、COM1 到 COM8、CON、CONFIG$、LPT1 到 LPT8、NUL 以及 PRN。
如果可能,拒绝包含以下字符的输入。
输入字符
使用类型安全的 SQL 参数
SQL Server 中的 Parameters 集合提供了类型检查和长度验证。如果使用 Parameters 集合,则输入将被当成文字值而不是可执行代码进行处理。使用 Parameters 集合的另一个好处是可以强制执行类型和长度检查。范围以外的值将触发异常。以下代码片断阐释了如何使用 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;
在上述示例中,@au_id 参数被当成文字值而不是可执行代码进行处理。将对此值进行类型和长度检查。如果 @au_id 值不符合指定的类型和长度约束,则将引发异常。
在存储过程中使用参数化输入
存储过程如果使用未筛选的输入,则可能容易受 SQL Injection 攻击。例如,以下代码容易受到攻击:
复制代码
SqlDataAdapter myCommand =
new SqlDataAdapter("LoginStoredProcedure '" +
Login.Text + "'", conn);
如果使用存储过程,则应使用参数作为存储过程的输入。
在动态 SQL 中使用参数集合
如果不能使用存储过程,您仍可使用参数,如下所示。
复制代码
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;
筛选输入
筛选输入可以删除转义符,这也可能有助于防止 SQL 注入;但由于可引起问题的字符数量很大,因此这并不是一种可靠的防护方法。以下代码片段可搜索字符串分隔符。
复制代码
private string SafeSqlLiteral(string inputSQL)
{
return inputSQL.Replace("'", "''");
}
LIKE 子句
请注意,如果要使用 LIKE 子句,还需要对通配符字符进行转义:
复制代码
s = s.Replace("[", "[[]");
s = s.Replace("%", "[%]");
s = s.Replace("_", "[_]");
参数批处理
有一种常见的错误概念,即,当多个 SQL 语句串联起来向服务器进行成批传输时,不能使用参数。事实上,只要参数名不重复,是可以使用参数的。保证每个名称唯一性的方法很简单,就是在 SQL 文本串联过程中,在每个参数名称中添加一个数字或其他唯一值。