sql注入，以及如何防止

1. sql注入

前一篇是关于编程防止SQL注入的文章，

那么这篇就是从测试来进行测试

SQL注入。

首先，看看SQL注入攻击能分为以下三种类型：

Inband:

数据经由SQL代码注入的通道取出，这是最直接的一种攻击，通过SQL注入获取的信息直接反映到应用程序的Web页面上；

Out-of-band：

 数据通过不同于SQL代码注入的方法获得(譬如通过邮件等)

推理：

这种攻击时说并没有真正的数据传输，但攻击者可以通过发送特定的

请求，重组返回的结果从而得到一些信息。

不论是哪种SQL注入，攻击者都需要构造一个语法正确的SQL查询，

如果应用程序对一个不正确的查询返回了一个错误消息，那么就很容易重新构造初始的查

询语句的逻辑，进而也就能更容易的进行注入；如果应用程序隐藏了错误信息，

那么攻击者就必须对查询逻辑进行反向工程，即我们所谓的“盲SQL注入” 

黑盒测试及其示例： 

这个测试的第一步是理解我们的应用程序在什么时候需要访问数据库，典型

的需要方法数据库的时机是：

认证表单：输入用户名和密码以检查是否有权限

搜索引擎：提交字符串以从数据库中获取相应的记录

 电子商务站点：获取某类商品的价格等信息

 作为测试人员，我们需要列对所有输入域的值可能用于查询的字段做一个表单，

包括那些POST请求的隐含字段，然后截取查询语句并产生错误信息。第一个测

试往往是用一个单引号“'”或者分号“;”，前者在SQL中是字符串终结符，如果应用程序没有过滤，则会产生一条错误信息；后者在SQL中是一条SQL语句的终结符，同样如果没有过滤，也会产生错误信息。

同样可用于测试的还有“--”以及SQL中的一些诸如“AND”的关键字，通常很常见的一种测试是在要求输入为数字的输入框中输入字符串。

通过上面的测试输入返回的错误信息能够让我们知道很多数据库的信息。这时候就需要“盲目SQL注入”了。注意，我们需要多所有可能存在的SQL注入漏洞的输入域进行测试，并且在，每个测试用例时只变化一个域的值，从而才能找到真正存在漏洞的输入域。

 下面看看一些常用例测试的

SQL注入语句。引用SELECT * FROM Users WHERE Username='$username' AND 

Password='$password'  

我们针对上面的

SQL语句分析，发现如果用下面的测试数据就能够进行SQL注入了引用$username = 1'or'1'='1  

$password=1'or'1'='1  

看看整个

SQL查询语句变成：

 引用SELECT * FROM Users WHERE Username='1' OR '1'='1' AND Password='1'OR '1'='1'  

 假设参数值是通过

GET方法传递到服务器的，且域名为www.example.com 

那么我们的访问请求就是：

  引用http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1&pass

word=1'%20or%20'1'%20=%20'1  

对上面的SQL语句作简单分析后我们就知道由于该语句永远为真，

所以肯定会返回一些数据，

在这种情况下实际上并未验证用户名和密码，

并且在某些系统中，用户表的第一行记录是管理员，那这样造成的后果则更为严重。

 另外一个查询的例子如下：

 引用SELECT * FROM Users 

WHERE((Username='$username')AND(Password=MD5('$password')))  

在这个例子中，存在两个问题，

一个是括号的用法，还有一个是MD5哈希函数的用法。

对于第一个问题，

我们很容找出缺少的右括号解决，

对于第二个问题，

我们可以想办法使第二个条件失效。我们在查询语句的最后加上一个注释符以表示

后面的都是注释，常见的注释起始符是

/*（在Oracle中是--），也就是说，我们用如下的用户名和密码： 

引用$username =1' or '1'='1'))/*  $password = foo  

 那么整条SQL语句就变为：

 引用SELECT * FROM Users WHERE(( Username='1'or '1'='1'))/*')AND 

(Password=MD5('$password')))  

 那么看看URL请求就变为：

  引用http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1'))/*

&password=foo  

Union查询SQL注入测试还有一种测试是利用Union的，利用Union可以连接查询，从而从其他表中得到信息，假设如下查询：

 引用 SELECT Name, Phone, Address FROM Users WHERE Id=$id  

 然后我们设置id的值为：引用

 $id =1 UNION ALL SELECT creditCardNumber,1,1 FROM CreditCarTable  

 那么整体的查询就变为：

 引用SELECT Name, Phone,Address FROM Users WHERE Id=1 UNION ALL SELECT 

creaditCardNumber,1,1 FROM CreditCarTable  

 显示这就能得到所有信用卡用户的信息。

  盲目SQL注入测试

  在上面我们提到过盲SQL注入，即bind SQL Injection,

它意味着对于某个操作我们得不到任何信息，通常这是由于程序员已经编写了特定的出错返回页面，从而隐藏了数据库结构的信息。但利用推理方法，有时候我们能够恢复特定字段的值。这种方法通常采用一组对服务器的布尔查询，依据返回的结果来推断结果的含义。仍然延续上面的www.example.com有一个参数名为id

，那么我们输入以下url请求：

  引用 http://www.exampe.com/index.php?id=1'  

 显然由于语法错误，我们会得到一个预先定义好的出错页面，假设服务器上的查

询语句为引用SELECT field1,field2,field3 FROM Users WHERE Id='$Id'   

 假设我们想要的带哦用户名字段的值，那么通过一些函数，我们就可以逐字符的

读取用户名的值。在这里我们使用以下的函数：

 引用 SUBSTRING(text,start,length), ASCII(char), LENGTH(text)  

 我们定义id为：

 引用$Id=1' AND ASCII(SUBSTRING(username,1,1))=97 AND '1'='1  

 那么最终的SQL查询语句为：

 引用

SELECT field1,field2,field3 FROM Users WHERE Id='1' AND 

ASCII(SUBSTRING(username,1,1))=97 AND '1'='1'  

那么，如果在数据库中有用户名的第一字符的ASCII码为97的话，那么我们就能得到一个真值u，那么就继续寻找该用户名的下一个字符；如果没有的话，那么我们就增猜测第一个字符ASCII

码为98的用户名，这样反复下去就能判断出合法的用户名。

不过这样盲目SQL注入会要求使用大量的SQL尝试，有一些自动化的工具能够帮我们实现，SqlDumper就是这样的一种工具，对MySql数据库进行GET访问请求。存储过程注入。如果在使用存储过程不当的时候，会造成一定的SQL注入漏洞。

 以下面的SQL存储过程为例：

引用

 Create procedure user_login  

@username varchar(20),  

@password varchar(20) As Declare @sqlstring varchar(250)  

 

Set @sqlstring =''  

Select 1 from users  

where username='+@username+'and password='+@password  

exec(@sqlstring)  

Go  

 

测试的输入如下：引用

 anyusername or 1=1'  

anypassword  

 如果程序没有对输入进行验证，那么上面的语句就返回数据库中的一条记录

我们再看下面的一条：

 引用

Create procedure get_report @columnamelist varchar(7900) As  

Declare @sqlstring varchar(8000)  

Set @sqlstring = ‘ 

Select ‘ + @columnamelist + ‘ from ReportTable‘ 

 exec(@sqlstring)  

Go   

如果测试输入是：

  

引用1 from users;update users set password='password';select *  

 后面显而易见，用户的所有密码都被更且得到了报表信息。

 

2、如何防范?

　　好在要防止应用被SQL注入式攻击闯入并不是一件特别困难的事情，只要在利用表单输入的内容构造SQL命令之前，把所有输入内容过滤一番就可以了。过滤输入内容可以按多种方式进行。

　　⑴对于动态构造SQL查询的场合，可以使用下面的技术:

　　第一:替换单引号，即把所有单独出现的单引号改成两个单引号，防止攻击者修改SQL命令的含义。再来看前面的例子，“SELECT * from Users WHERE login = ''' or ''1''=''1' AND password = ''' or ''1''=''1'”显然会得到与“SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'”不同的结果。

　　第二:删除用户输入内容中的所有连字符，防止攻击者构造出类如“SELECT * from Users WHERE login = 'mas' -- AND password =''”之类的查询，因为这类查询的后半部分已经被注释掉，不再有效，攻击者只要知道一个合法的用户登录名称，根本不需要知道用户的密码就可以顺利获得访问权限。

　　第三:对于用来执行查询的数据库帐户，限制其权限。用不同的用户帐户执行查询、插入、更新、删除操作。由于隔离了不同帐户可执行的操作，因而也就防止了原本用于执行SELECT命令的地方却被用于执行INSERT、UPDATE或DELETE命令。

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

　　⑶限制表单或查询字符串输入的长度。如果用户的登录名字最多只有10个字符，那么不要认可表单中输入的10个以上的字符，这将大大增加攻击者在SQL命令中插入有害代码的难度。

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

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

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

　　⑹检查提取数据的查询所返回的记录数量。如果程序只要求返回一个记录，但实际返回的记录却超过一行，那就当作出错处理。