SQL注入攻击实例

一位客户让我们针对只有他们企业员工和顾客能使用的企业内网进行渗透测试。这是安全评估的一个部分，所以尽管我们之前没有使用过SQL注入来渗透网络，但对其概念也相当熟悉了。最后我们在这项任务中大获成功，现在来回顾一下这个过程的每一步，将它记录为一个

一位客户让我们针对只有他们企业员工和顾客能使用的企业内网进行渗透测试。这是安全评估的一个部分，所以尽管我们之前没有使用过SQL注入来渗透网络，但对其概念也相当熟悉了。最后我们在这项任务中大获成功，现在来回顾一下这个过程的每一步，将它记录为一个案例。

我们记录下了在多次错误的转折后经历的曲折过程，而一个更有经验的人会有这不同的 — 甚至更好的 — 方法。但事实上我们成功以后才明白，我们并没有完全被误导。

其他的SQL文章包含了更多的细节，但是这篇文章不仅展示了漏洞利用的过程，还讲述了发现漏洞的原理。

目标内网

展现在我们眼前的是一个完整定制网站，我们之前没见过这个网站，也无权查看它的源代码：这是一次“黑盒”攻击。‘刺探’结果显示这台服务器运行在微软的IIS6上，并且是ASP.NET架构。这就暗示我们数据库是微软的SQL server：我们相信我们的技巧可以应用在任何web应用上，无论它使用的是哪种SQL 服务器。

登陆页有传统的用户-密码表单，但多了一个 “把我的密码邮给我”的链接；后来，这个地方被证实是整个系统陷落的关键。

当键入邮件地址时，系统假定邮件存在，就会在用户数据库里查询邮件地址，然后邮寄一些内容给这个地址。但我的邮件地址无法找到，所以它什么也不会发给我。

对于任何SQL化的表单而言，第一步测试，是输入一个带有单引号的数据：目的是看看他们是否对构造SQL的字符串进行了过滤。当把单引号作为邮件地址提交以后，我们得到了500错误（服务器错误），这意味着“有害”输入实际上是被直接用于SQL语句了。就是这了！

我猜测SQL代码可能是这样：

[sql] view plaincopy

1. SELECT fieldlist  
2.   FROM table  
3.  WHERE field = '$EMAIL';  

$EMAIL 是用户从表单提交的地址，并且这段查询在字符串末端$EMAIL上提供了引号。我们不知道字段或表的确切名字，但是我们了解他们的本质，这有助于我们做正确的猜测。

当我们键入 steve@unixwiz.net‘ -注意这个末端的引号 – 下面是这个SQL字段的构成：

[sql] view plaincopy

1. SELECT fieldlist  
2.   FROM table  
3.  WHERE field = 'steve@unixwiz.net'';  

当这段SQL开始执行，SQL解析器就会发现多余的引号然后中断执行，并给出语法错误的提示。这个错误如何清楚的表述给用户，基于应用内部的错误恢复规程，但一般来说都不会提示“邮件地址不存在”。这个错误响应成了死亡之门，它告诉别人用户输入没有被正确的处理，这就为应用破解留下了可乘之机。

这个数据呈现在WHERE的从句中，让我们以符合SQL规范的方式改变输入试试，看看会发生什么。键入anything’ OR ‘x’=‘x, 结果如下：

[sql] view plaincopy

1. SELECT fieldlist FROM table WHERE field = 'anything' OR 'x'='x';  

因为应用不会思考输入 – 仅仅构造字符串 - 我们使用单引号把WHERE从句的单一组成变成了双组成，’x'=‘x’从句是恒成立的，无论第一个从句是什么。（有一种更好的方式来确保“始终为真”，我们随后会接触到）。

但与每次只返回单一数据的“真实”查询不同，上面这个构造必须返回这个成员数据库的所有数据。要想知道在这种情况下应用会做什么，唯一的方法就是尝试，尝试，再尝试。我们得到了这个：

---

你的登录信息已经被邮寄到了 random.person@example.com.

---

我们猜测这个地址是查询到的第一条记录。这个家伙真的会在这个邮箱里收到他忘记的密码，想必他会很吃惊也会引起他的警觉。

我们现在知道可以根据自己的需要来篡改查询语句了，尽管对于那些看不到的部分还不够了解，但是我们注意到了在多次尝试后得到了三条不同的响应：

• “你的登录信息已经被邮寄到了邮箱”
• “我们不能识别你的邮件地址”
• 服务器错误

前两个响应是有效的SQL，最后一个响应是无效的SQL：当猜测查询语句结构的时候，这种区别非常有用。

模式字段映射

第一步是猜测字段名：我们合理的推测了查询包含“email address”和“password”，可能也会有“US Mail address”或者“userid”或“phone number”这样的字段。我们特别想执行 SHOW TABLE语句, 但我们并不知道表名，现在没有比较明显的办法可以拿到表名。

我们进行了下一步。在每次测试中，我们会用我们已知的部分加上一些特殊的构造语句。我们已经知道这个SQL的执行结果是email地址的比对，因此我们来猜测email的字段名:

[sql] view plaincopy

1. SELECT fieldlist FROM table WHERE field = 'x' AND email IS NULL; --';  

目的是假定的查询语句的字段名（email），来试试SQL是不是有效。我不关心匹配的邮件地址是啥（我们用了个伪名’x’），’ ——’这个符号表示SQL注释的起始。对于去除应用末尾提供的引号，这是一个很有效的方式，我们不用在乎我们屏蔽掉的是啥。

如果我们得到了服务器错误，意味着SQL有不恰当的地方，并且语法错误会被抛出：更有可能是字段名有错。如果我们得到了任何有效的响应，我们就可以猜测这个字段名是正确的。这就是我们得到“email unknown”或“password was sent”响应的过程。

我们也可以用AND连接词代替OR:这是有意义的。在SQL的模式映射阶段，我们不需要为猜一个特定的邮件地址而烦恼，我们也不想应用随机的泛滥的给用户发“这是你的密码”的邮件 - 这不太好，有可能引起怀疑。而使用AND连接邮件地址，就会变的无效，我们就可以确保查询语句总是返回0行，永远不会生成密码提醒邮件。

提交上面的片段的确给了我们“邮件地址未知”的响应，现在我们知道邮件地址的确是存储在email字段名里。如果没有生效，我们可以尝试email_address或mail这样的字段名。这个过程需要相当多的猜测。

接下来，我们猜测其他显而易见的名字：password，user ID, name等等。每次只猜一个字段，只要响应不是“server failure”，那就意味着我们猜对了。

[sql] view plaincopy

1. SELECT fieldlist FROM table WHERE email = 'x' AND userid IS NULL; --';  

在这个过程中，我们找到了几个正确的字段名：

• email
• passwd
• login_id
• full_name

无疑还有更多（有一个线索是表单中的字段名），一阵挖掘后没有发现更多了。但是我们依然不知道这些字段名的表名，它们在哪找到的？

寻找数据库表名

应用的内建查询指令已经建立了表名，但是我们不知道是啥：有几个方法可以找到表名。其中一个是依靠subselect（字查询）。

一个独立的查询

[sql] view plaincopy

1. SELECT COUNT(*) FROM tabname  

返回表里记录的数量，如果表名无效，查询就会失败。我们可以建立自己的字符串来探测表名：

[sql] view plaincopy

1. SELECT email, passwd, login_id, full_name  
2.   FROM table  
3.  WHERE email = 'x' AND 1=(SELECT COUNT(*) FROM tabname); --';  

我们不关心到底有多少条记录，只关心表名是不是正确。重复多次猜测以后，我们终于发现members是这个数据库里的有效表名。但它是用在这个查询里的么？所以我们需要另一个测试，使用table.field：实际查询的部分只工作在这个表中，而不是只要表存在就执行。

[sql] view plaincopy

1. SELECT email, passwd, login_id, full_name FROM members WHERE email = 'x'  
2.                     AND members.email IS NULL; --';  

当返回“Email unknown”时，就意味着我们的SQL注入成功了，并且我们正确的猜测出了表名。这对后面的工作很重要，但是我们暂时先试试其他的方法。

找用户账号

我们对members表的结构有了一个局部的概念，但是我们仅知道一个用户名：任意用户都可能得到“Here is your password”的邮件。回想起来，我们从未得到过信息本身，只有它发送的地址。我们得再弄几个用户名，这样就能得到更多的数据。

首先，我们从公司网站开始找几个人：“About us”或者“Contact”页通常提供了公司成员列表。通常都包含邮件地址，即使它们没有提供这个列表也没关系，我们可以根据某些线索用我们的工具找到它们。

LIKE从句可以进行用户查询，允许我们在数据库里局部匹配用户名或邮件地址，每次提交如果显示“We sent your password”的信息并且邮件也真发了，就证明生效了。

警告：这么做拿到了邮件地址，但也真的发了邮件给对方，这有可能引起怀疑，小心使用。

我们可以查询email name或者full name（或者推测出来的其他信息），每次放入%通配符进行如下查询：

[sql] view plaincopy

1. SELECT email, passwd, login_id, full_name  
2.   FROM members  
3.  WHERE email = 'x' OR full_name LIKE '%Bob%';  

记住尽管可能不只有一个“Bob”，但我们只能看到一条信息：建议精炼LIKE从句。

密码暴力破解

可以肯定的是，我们能在登陆页进行密码的暴力破解，但是许多系统都针对此做了监测甚至防御。可能有的手段有操作日志，帐号锁定，或者其他能阻碍我们行动的方式，但是因为存在未过滤的输入，我们就能绕过更多的保护措施。

我们在构造的字符串里包含进邮箱名和密码来进行密码测试。在我们的例子中，我们用了受害者bob@example.com 并尝试了多组密码。

[sql] view plaincopy

1. SELECT email, passwd, login_id, full_name FROM members WHERE email = '
2.                         href="mailto:bob@example.com">bob@example.com' AND passwd  
3.                         = 'hello123';  

这是一条很好使的SQL语句，我们不会得到服务器错误的提示，只要我们得到“your password has been mailed to you”的提示信息，就证明我们已经得到密码了。这时候受害人可能会警觉起来，但谁关心他呢，我们已经得到密码了。

这个过程可以使用perl脚本自动完成，然而，我们在写脚本的过程中，发现了另一种方法来破解系统。

数据库不是只读的

迄今为止，我们没做查询数据库之外的事，尽管SELECT是只读的，但不代表SQL只能这样。SQL使用分号表示结束，如果输入没有正确过滤，就没有什么能阻止我们在字符串后构造与查询无关的指令。

The most drastic example is:

这剂猛药是这样的：

[sql] view plaincopy

1. SELECT email, passwd, login_id, full_name  
2.   FROM members  
3.  WHERE email = 'x'; DROP TABLE members; --';  -- Boom!  

第一部分我们准备了一个伪造的email地址——‘X’——我们不关心查询结果返回什么：我们想要得到的只是我们自己构造的SQL指令。这次攻击删除了整个members表，这就不太好玩了。

这表明我们不仅仅可以切分SQL指令，而且也可以修改数据库。这是被允许的。

添加新用户

我们已经了解了members表的局部结构，添加一条新纪录到表里视乎是一个可行的方法：如果这成功了，我们就能简单的用我们新插入的身份登陆到系统了。

不要太惊讶，这条SQL有点长，我们把它分行显示以便于理解，但它依然是一条语句：

[sql] view plaincopy

1. SELECT email, passwd, login_id, full_name  
2.   FROM members  
3.  WHERE email = 'x';  
4.         INSERT INTO members ('email','passwd','login_id','full_name')   
5.         VALUES ('steve@unixwiz.net','hello','steve','Steve Friedl');--';  

即使我们得到了正确的字段名和表名，但在成功攻击之前我们还有几件事需要了解：

1. 在web表单里，我们可能没有足够的空间键入这么多文本（尽管可以用脚本解决，但并不容易）。
2. web应用可能没有members表的INSERT权限。
3. 母庸置疑，members表里肯定还有其他字段，有一些可能需要初始值，否则会引起INSERT失败。
4. 即使我们插入了一条新纪录，应用也可能不正常运行，因为我们无法提供值的字段名会自动插入NULL。
5. 一个正确的“member”可能额不仅仅只需要members表里的一条纪录，而还要结合其他表的信息（如，访问权限），因此只添加一个表可能不够。

在这个案例里，我们遇到了问题#4或#5，我们无法确定到底是哪个—— 因为用构造好的用户名登陆进去的时候，返回了服务器错误的提示。尽管这就暗示了我们那些没有构造的字段是必须的，但我们没有办法正确处理。

一个可行的办法是猜测其他字段，但这是一个劳力费神的过程：尽管我们可以猜测其他“显而易见”的字段，但要想得到整个应用的组织结构图太难了。

我们最后尝试了其他方式。

把密码邮给我

我们意识到虽然我们无法添加新纪录到members数据库里，但我们可以修改已经存在的，这被证明是可行的。

从上一步得知 bob@example.com 账户在这个系统里，我们用SQL注入把数据库中的这条记录改成我们自己的email地址：

[sql] view plaincopy

1. SELECT email, passwd, login_id, full_name FROM members WHERE email = 'x';  
2.                             UPDATE members SET email = "mailto:'steve@unixwiz.net">'steve@unixwiz.net'  
3.                             WHERE email = "mailto:'bob@example.com"