浅谈SQL注入攻击的方法及其防范

摘 要： 随着Internet在全球的广泛普及， Web应用越来越广泛，使用B/S模式编写的应用程序越来越多， SQL注入攻击是Web应用中一个重要的安全问题，同时也是一种常用的且易于实现的入侵手段。攻击者通过检测网页地址的注入入口，进而构造具有某种危害的SQL语句，从而完成对网站的注入攻击。

关键词： SQL注入；攻击方法；防范措施

1 SQL注入攻击原理

SQL注入攻击的基本原理就是在用户输入中注入一些额外的特殊符号或SQL语句，使系统构造出来的SQL语句在执行时或者改变了查询条件，或者附带执行了攻击者注入的整个SQL语句，从而让攻击者达到了非法的目的。由于SQL注入攻击利用的是SQL语法，使得这种攻击具有广泛性。理论上说，对于所有基于SQL语言标准的数据库软件都是有效的，包括MSSQL Server、Oracle、DB2、Sybase、MySQL等。只要这个恶意代码符合SQL语句的规则，则在代码编译与执行的时候，就不会被系统所发现。它的产生主要是由于程序对用户输入的数据没有进行细致的过滤，导致非法数据的导入查询。

2 SQL注入的方法

对一些存在SQL注入漏洞的应用系统来说，利用这些漏洞，攻击者可以窃取用户数据，提升权限等，根据注入方式的不同，注入方法主要有以下几种：

2.1 没有正确或不严格过滤转义字符

在用户的输入没有为转义字符过滤时，就会发生这种形式的注入式攻击，它会被传递给一个SQL语句。这样就会导致应用程序的终端用户对数据库上的语句实施操纵。比方说，下面的这行代码就会演示这种漏洞：

SELECT * FROM userTable WHERE name = '" + userName + "'；

这种代码的设计目的是将一个特定的用户从其用户表中取出，但是，如果用户名被一个恶意的用户用一种特定的方式伪造，这个语句所执行的操作可能就不仅仅是代码的作者所期望的那样了。例如，将用户名变量（即username）设置为：

a' or 't'='t，此时原始语句发生了变化：

SELECT * FROM users WHERE name = 'a' OR 't'='t'；

如果这种代码被用于一个认证过程，那么这个例子就能够强迫选择一个合法的用户名，因为赋值't'='t永远是正确的。

在一些SQL服务器上，如在SQL Server中，任何一个SQL命令都可以通过这种方法被注入，包括执行多个语句。下面语句中的username的值将会导致删除“users”表，又可以从“data”表中选择所有的数据（实际上就是透露了每一个用户的信息）。

a'； DROP TABLE userTable； SELECT * FROM data WHERE name LIKE '%

这就将最终的SQL语句变成下面这个样子：

SELECT * FROM userTable WHERE name = 'a'； DROP TABLE userTable； SELECT * FROM DATA WHERE name LIKE '%'；

其它的SQL执行不会将执行同样查询中的多个命令作为一项安全措施。这会防止攻击者注入完全独立的查询，不过却不会阻止攻击者修改查询。

2.2 类型不正确的处理

如果一个用户提供的字段并非一个强类型，或者没有实施类型强制，就会发生这种形式的攻击。当在一个SQL语句中使用一个数字字段时，如果程序员没有检查用户输入的合法性（是否为数字型）就会发生这种攻击。例如：

SELECT * FROM data WHERE id = " + a_variable + "；

从这个语句可以看出，作者希望a_variable是一个与“id”字段有关的数字。不过，如果终端用户选择一个字符串，就绕过了对转义字符的需要。例如，将a_variable设置为：1； DROP TABLE userTable，它会将“userTable”表从数据库中删除，SQL语句变成：SELECT * FROM DATA WHERE id = 1； DROP TABLE users；

2.3 数据库服务器中的漏洞

有时，数据库服务器软件中也存在着漏洞，如SQL Server服务器漏洞。例如：分别由NameTxt，PwdTxt接受页面输入用户名和密码，然后构造如下sql语句：

select * from [User] where userName = '" + NameTxt + "'and userPassword = '" + PwdTxt + "'"；

比如你的用户名为your，我不知道密码，但是我在"用户名"处输入 your '--"select * from [User] where userName='your '-- 'and userPassword =....

注意"--"，会把后边的sql作为注释。

2.4 盲目SQL注入式攻击

当一个Web应用程序易于遭受攻击而其结果对攻击者却不见时，就会发生所谓的盲目SQL注入式攻击。有漏洞的网页可能并不会显示数据，而是根据注入到合法语句中的逻辑语句的结果显示不同的内容。这种攻击相当耗时，因为必须为每一个获得的字节而精心构造一个新的语句。但是一旦漏洞的位置和目标信息的位置被确立以后，一种称为Absinthe的工具就可以使这种攻击自动化。

2.5 条件响应

注意，有一种SQL注入迫使数据库在一个普通的应用程序屏幕上计算一个逻辑语句的值：SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND 1=1

这会导致一个标准的面面，而语句SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND 1=2在页面易于受到SQL注入式攻击时，它有可能给出一个不同的结果。如此这般的一次注入将会证明盲目的SQL注入是可能的，它会使攻击者根据另外一个表中的某字段内容设计可以评判真伪的语句。

2.6 条件性差错

如果WHERE语句为真，这种类型的盲目SQL注入会迫使数据库评判一个引起错误的语句，从而导致一个SQL错误。例如：

SELECT 1/0 FROM users WHERE username='Your'。显然，如果用户Your存在的话，被零除将导致错误。

2.7 时间测定

时间测定注入则是在注入语句中加入像“ wait for 100”这样的语句，根据该查询结果出现的时间来判定是否能注入、注入是否成功以及推导数据值的范围。这些方法都是通过问一些相关但并非直接且能得到回应的问题，从响应信息推出想要的信息，进而进行攻击。

以上仅是对SQL攻击的粗略分类。但从技术上讲，如今的SQL注入攻击者们在如何找出有漏洞的网站方面更加聪明，也更加全面了。出现了一些新型的SQL攻击手段。攻击者们可以使用各种工具来加速漏洞的利用过程。

3 SQL注入防范

了解了SQL注入的方法，如何能防止SQL注入？如何进一步防范SQL注入的泛滥？通过一些合理的操作和配置来降低SQL注入的危险。

3.1 使用参数化的过滤性语句

要防御SQL注入，用户的输入就绝对不能直接被嵌入到SQL语句中。恰恰相反，用户的输入必须进行过滤，或者使用参数化的语句。参数化的语句使用参数而不是将用户输入嵌入到语句中。在多数情况中，SQL语句就得以修正。然后，用户输入就被限于一个参数。

3.2 输入验证

检查用户输入的合法性，确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行之所以要执行服务器端验证，是为了弥补客户端验证机制脆弱的安全性。

在客户端，攻击者完全有可能获得网页的源代码，修改验证合法性的脚本（或者直接删除脚本），然后将非法内容通过修改后的表单提交给服务器。因此，要保证验证操作确实已经执行，唯一的办法就是在服务器端也执行验证。你可以使用许多内建的验证对象，例如Regular Expression Validator，它们能够自动生成验证用的客户端脚本，当然你也可以插入服务器端的方法调用。如果找不到现成的验证对象，你可以通过Custom Validator自己创建一个。

3.3 错误消息处理

防范SQL注入，还要避免出现一些详细的错误消息，因为黑客们可以利用这些消息。要使用一种标准的输入确认机制来验证所有的输入数据的长度、类型、语句、企业规则等。

3.4 加密处理

将用户登录名称、密码等数据加密保存。加密用户输入的数据，然后再将它与数据库中保存的数据比较，这相当于对用户输入的数据进行了“消毒”处理，用户输入的数据不再对数据库有任何特殊的意义，从而也就防止了攻击者注入SQL命令。

3.5 存储过程来执行所有的查询

SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外，它还使得数据库权限可以限制到只允许特定的存储过程执行，所有的用户输入必须遵从被调用的存储过程的安全上下文，这样就很难再发生注入式攻击了。

3.6 使用专业的漏洞扫描工具

攻击者们目前正在自动搜索攻击目标并实施攻击，其技术甚至可以轻易地被应用于其它的Web架构中的漏洞。企业应当投资于一些专业的漏洞扫描工具，如大名鼎鼎的Acunetix的Web漏洞扫描程序等。一个完善的漏洞扫描程序不同于网络扫描程序，它专门查找网站上的SQL注入式漏洞。最新的漏洞扫描程序可以查找最新发现的漏洞。

3.7 确保数据库安全

锁定你的数据库的安全，只给访问数据库的web应用功能所需的最低的权限，撤销不必要的公共许可，使用强大的加密技术来保护敏感数据并维护审查跟踪。如果web应用不需要访问某些表，那么确认它没有访问这些表的权限。如果web应用只需要只读的权限，那么就禁止它对此表的 drop 、insert、update、delete 的权限，并确保数据库打了最新补丁。

3.8 安全审评

在部署应用系统前，始终要做安全审评。建立一个正式的安全过程，并且每次做更新时，要对所有的编码做审评。开发队伍在正式上线前会做很详细的安全审评，然后在几周或几个月之后他们做一些很小的更新时，他们会跳过安全审评这关， “就是一个小小的更新，我们以后再做编码审评好了”。请始终坚持做安全审评。

本文总结了一些常见的SQL注入攻击的方式，提出了一些防范SQL注入攻击的方法，希望能对一些Web应用在防注入方面提供帮助，但是新的注入方式层出不穷，SQL注入与防范一直会是Web应用安全方面经久不衰的话题。