【转载】SQL注入

“SQL注入”是一种利用未过滤/未审核用户输入的攻击方法（“缓存溢出”和这个不同），意思就是让应用运行本不应该运行的SQL代码。如果应用毫无防备地创建了SQL字符串并且运行了它们，就会造成一些出人意料的结果。本篇译文由zer0Black翻译自《SQL Injection Attacks by Example》。

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

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

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

目标内网

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

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

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

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

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

[sql] view plain copy

SELECT fieldlist
FROM table
WHERE field = '$EMAIL';

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

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

[sql] view plain copy

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

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

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

[sql] view plain copy

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 plain copy

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 plain copy

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

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

passwd

login_id

full_name

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

寻找数据库表名

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

一个独立的查询

[sql] view plain copy

SELECT COUNT(*) FROM tabname

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

[sql] view plain copy

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

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

[sql] view plain copy

SELECT email, passwd, login_id, full_name FROM members WHERE email = 'x'
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 plain copy

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

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

密码暴力破解

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

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

[sql] view plain copy

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

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

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

数据库不是只读的

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

The most drastic example is:

这剂猛药是这样的：

[sql] view plain copy

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

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

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

添加新用户

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

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

[sql] view plain copy

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

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

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

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

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

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

把密码邮给我

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

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

[sql] view plain copy

SELECT email, passwd, login_id, full_name FROM members WHERE email = 'x';
UPDATE members SET email = <a href="mailto:'steve@unixwiz.net">'steve@unixwiz.net</a>'
WHERE email = <a href="mailto:'bob@example.com">'bob@example.com</a>';

运行之后，我们自然得到了“we didn’t know your email address”的提示，但这在预料之中，毕竟我们用了假的email地址。UPDATE操作不会通知应用，因此它悄然执行了。

之后，我们使用了“I lost my password”的功能，用我们刚刚更新的email地址，一分钟后，我们收到了这封邮件：

[sql] view plain copy

From: <a href="mailto:system@example.com">system@example.com</a>
To: <a href="mailto:steve@unixwiz.net">steve@unixwiz.net</a>
Subject: Intranet login This email is in response to your request for your
Intranet log in information. Your User ID is: bob Your password is: hello

现在，我们要做的就是跟随标准的登录流程进入系统，这是一个高等级职员，有高级权限，比我们INSERT的用户要好。

我们发现这个企业内部站点内容特别多，甚至包含了一个全用户列表，我们可以合理的推出许多内网都有同样的企业Windows网络帐号，它们可能在所有地方都使用同样的密码。我们很容易就能得到任意的内网密码，并且我们找到了企业防火墙上的一个开放的PPTP协议的VPN端口，这让登录测试变得更简单。

我们又挑了几个帐号测试都没有成功，我们无法知道是否是“密码错误”或者“企业内部帐号是否与Windows帐号名不同”。但是我们觉得自动化工具会让这项工作更容易。

其他方法

在这次特定的渗透中，我们得到了足够的权限，我们不需要更多了，但是还有其他方法。我们来试试我们现在想到的但不够普遍的方法。

我们意识到不是所有的方法都与数据库无关，我们可以来试试。

调用xp_cmdshell

微软的SQLServer支持存储过程xp_cmdshell有权限执行任意操作系统指令。如果这项功能允许web用户使用，那webserver被渗透是无法避免的。

迄今为止，我们做的都被限制在了web应用和数据库这个环境下，但是如果我们能执行任何操作系统指令，再厉害的服务器也禁不住渗透。xp_cmdshell通常只有极少数的管理员账户才能使用，但它也可能授权给了更低级的用户。

绘制数据库结构

在这个登录后提供了丰富功能应用上，已经没必要做更深的挖掘了，但在其他限制更多的环境下可能还不够。

能够系统的绘制出数据库可见结构，包含表和它们的字段结构，可能没有直接帮助。但是这为网站渗透提供了一条林萌大道。

从网站的其他方面收集更多有关数据结构的信息（例如，“留言板”页？“帮助论坛”等？）。不过这对应用环境依赖强，而且还得靠你准确的猜测。

减轻危害

我们认为web应用开发者通常没考虑到“有害输入”，但安全人员应该考虑到（包括坏家伙），因此这有3条方法可以使用。

输入过滤

过滤输入是非常重要的事，以确保输入不包含危险代码，无论是SQL服务器或HTM本身。首先想到的是剥掉“恶意字符”，像引号、分号或转义符号，但这是一种不太好的方式。尽管找到一些危险字符很容易，但要把他们全找出来就难了。

web语言本身就充满了特殊字符和奇怪的标记（包括那些表达同样字符的替代字符），所以想要努力识别出所有的“恶意字符”不太可能成功。

换言之，与其“移除已知的恶意数据”，不如移除“良好数据之外的所有数据”：这种区别是很重要的。在我们的例子中，邮件地址仅能包含如下字符：

[text] view plain copy

abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789 @.-_+

允许不正确的字符输入是没有任何好处的，应该早点拒绝它们 - 可能会有一些错误信息 – 不仅可以阻止SQL注入，也可以捕获一些输入错误而不是把它们存入数据库。

某个特殊的email地址会让验证程序陷入麻烦，因为每个人对于“有效”的定义不同。由于email地址中出现了一个你没有考虑到的字符而被拒绝，那真是糗大了。

真正的权威是 RFC 2822（比RFC822内容还多），它对于”允许使用的内容“做了一个规范的定义。这种更学术的规范希望可以接受&和*（还有更多）作为有效的email地址，但其它人 - 包括作者 – 都乐于用一个合理的子集来包含更多的email地址。

那些采用更限制方法的人应当充分意识到没有包含这些地址会带来的后果，特别是限制有了更好的技术（预编译/执行，存储过程）来避免这些“奇怪”的字符带来的安全问题。

意识到“过滤输入”并不意味着仅仅是“移除引号”，因为即使一个“正规”的字符也会带来麻烦。在下面这个例子中，一个整型ID值被拿来和用户的输入作比较（数字型PIN）:

[sql] view plain copy

SELECT fieldlist FROM table WHERE id = 23 OR 1=1; -- Boom! Always matches!

在实践中，无论如何这个方法都有诸多限制，因为能够彻底排除所有危险字符的字段实在太少了。对于“日期”或者“email地址”或者“整型”，上面的办法是有价值的，但对于真实的环境，我们不可避免地要使用其他方式来减轻危害。

输入项编码/转义

现在可以过滤电话号码和邮件地址了，但你不能通过同样的方法处理“name”字段，要不然可能会排除掉Bill O’Reilly这样的名字：对于这个字段，这里的引号是合法的输入。

有人就想到过滤到单引号的时候，再加上一个引号，这样就没问题了 – 但是这么干要出事啊！

预处理每个字符串来替换单引号：

[sql] view plain copy

SELECT fieldlist
FROM customers
WHERE name = 'Bill O''Reilly'; -- works OK

这个方法很容易出问题，因为大部分数据库都支持转码机制。像MySQL，允许输入’来替代单引号，因此如果输入 ‘; DROP TABLE users; — 时，通过两次引号来“保护”数据库，那我们将得到：

[sql] view plain copy

SELECT fieldlist
FROM customers
WHERE name = '\''; DROP TABLE users; --'; -- Boom!

‘’’ 是一个完整的SQL语句（只包含一个引号），通常，恶意SQL代码就会紧跟其后。不光是反斜线符号的情况：像Unicode编码，其他的编码或者解析规则都会无意中给程序员挖坑。完美的过滤的很困难的，这就是为什么许多的数据库借口语言都提供函数给你使用。当同样的内容给“string quoting”和“string parsing”处理过后，会好一些，也更安全一些。

比如MySQL的函数mysql_real_escape_string()和perl DBD 的 $dbh->quote($value)方法，这些方法都是必用的。

参数绑定 (预编译语句)

尽管转义是一个有用的机制，但我们任然处于“用户输入被当做SQL语句”这么一个循环里。更好的方法是：预编译，本质上所有的数据库编程接口都支持预编译。技术上来说，SQL声明语句是用问号给每个参数占位创建的 – 然后在内部表中进行编译。

预编译查询执行时是按照参数列表来的：

Perl中的例子

[sql] view plain copy

$sth = $dbh->prepare("SELECT email, userid FROM members WHERE email = ?;");
$sth->execute($email);

感谢Stefan Wagner帮我写了个java实现：

不安全版

[sql] view plain copy

Statement s = connection.createStatement();
ResultSet rs = s.executeQuery("SELECT email FROM member WHERE name = "
+ formField); // *boom*

安全版

[sql] view plain copy

PreparedStatement ps = connection.prepareStatement(
"SELECT email FROM member WHERE name = ?");
ps.setString(1, formField);
ResultSet rs = ps.executeQuery();

$email 是从用户表单获得的，它作为#1（第一个问号标记的地方）位置的参数传递过来，在任何情况下这条SQL声明都可以解析。引号，分号，反斜杠，SQL指令记号 – 任何字符都不会产生特殊效果，因为它们“只是数据”而已。这不会对其他东西造成破坏，因此这个应用很大程度上防范了SQL注入攻击。

如果预编译查询语句多次（只编译一次）执行，也会带来性能上的提升，但是与大量安全方面的巨大提升相比，这显得微不足道。这可能是我们保证web应用安全最重要的一步。

限制数据库权限和隔离用户

在这个案例中，我们观察到只有两个交互动作不在登录用户的上下文环境中：“登录”和“发密码给我”。web应用应该对数据库连接做权限的限制：对于members表只能读，并且无法操作其他表。

作用是即使一次“成功的”SQL注入攻击也只能得到非常有限的成功。噢，我们将不能做有授权的UPDATE请求，我们要求助于其他方法。

一旦web应用确定登录表单传递来的认证是有效的，它就会切换会话到一个有更多权限的用户上。

对任何web应用而言，不使用sa权限几乎是根本不用说的事。

对数据库的访问采用存储过程

如果数据库支持存储过程，请使用存储过程来执行数据库的访问行为，这样就不需要SQL了（假设存储过程编程正确）。

把查询，更新，删除等动作规则封装成一个单独的过程，就可以针对基础规则和所执行的商业规则来完成测试和归档（例如，如果客户超过了信用卡限额，“添加新记录”过程可能拒绝订单）。

对于简单的查询这样做可能仅仅能获得很少的好处，不过一旦操作变复杂（或者被用在更多地方），给操作一个单独的定义，功能将会变得更稳健也更容易维护。

注意：动态构建一个查询的存储过程是可以做到的：这么做无法防止SQL注入 – 它只不过把预编译/执行绑定到了一起，或者是把SQL语句和提供保护的变量绑定到了一起。

隔离Web服务器

实施了以上所有的防御措施，仍然可能有某些地方有遗漏，导致了服务器被渗透。设计者应该在假定坏蛋已经获得了系统最高权限下来设计网络设施，然后把它的攻击对其他事情产生的影响限制在最小。

例如，把这台机器放置在极度限制出入的DMZ网络“内部”，这么做意味着即便取得了web服务器的完全控制也不能自动的获得对其他一切的完全访问权限。当然，这么做不能阻止所有的入侵，不过它可以使入侵变的非常困难。

配置错误报告

一些框架的错误报告包含了开发的bug信息，这不应该公开给用户。想象一下：如果完整的查询被现实出来了，并且指出了语法错误点，那要攻击该有多容易。

对于开发者来说这些信息是有用的，但是它应该禁止公开 – 如果可能 - 应该限制在内部用户访问。

注意：不是所有的数据库都采用同样的方式配置，并且不是所有的数据库都支持同样的SQL语法（“S”代表“结构化”，不是“标准的”）。例如，大多数版本的MySQL都不支持子查询，而且通常也不允许单行多条语句（multiple statements）：当你渗透网络时，实际上这些就是使问题复杂化的因素。

再强调一下，尽管我们选择了“忘记密码”链接来试试攻击，但不是因为这个功能不安全。而是几个易攻击的点之一，不要把焦点聚集在“忘记密码”上。

这个教学示例不准备全面覆盖SQL注入的内容，甚至都不是一个教程：它仅仅是一篇我们花了几小时做的渗透测试的记录。我们看了其他的关于SQL注入文章的讨论，但它们只给出了结果而没有给出过程。

但是那些结果报告需要技术背景才能看懂，并且渗透细节也是有价值的。在没有源代码的情况下，渗透人员的黑盒测试能力也是有价值的。