[常用Sql注入语句.docVIP

如何防范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 = 1or1=1 $password=1or1=1 看看整个SQL查询语句变成： 引用 SELECT * FROM Users WHERE Username=1 OR 1=1 AND Password=1OR 1=1 假设参数值是通过GET方法传递到服务器的，且域名为 那么我们的访问请求就是： 引用 　　/index.php?username=1%20or%201%20=%201password=1%20or%201%20=%201 ? 对上面的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=1or 1=1))/*)AND (Password=MD5($password))) 那么看看URL请求就变为： 引用 /index.php?username=1%20or%201%20=%201))/*password=foo Union查询SQL注入测试 ? 还有一种测试是利用Union的，利用Union可以连接查询，从而从其他表中得到信息，假设如下查询： 引用 ? SELECT Name, Phone, Address FROM Users WHERE Id=$