SQL注入(三)

邮给我一个密码

我们意识到虽然不能添加一条新的记录在members表中，但我们可以通过修改一个存在的记录, 这也获得了我们的证明是可行的。

从先前的步骤中，我们知道[email protected]在系统中有一个帐号，我们使用SQL注入更新了他的数据库记录为我们的邮件地址：

1. SELECT email, passwd, login_id, full_name 
2.   FROM members 
3.  WHERE email = ‘x‘; UPDATE members SET email = ‘[email protected]‘ WHERE email = ‘[email protected]‘; 

运行这个之后，我们当然会收到"we didn‘t know your email address"消息，但这是预期的提供了不正确的邮件地址。UPDATE操作并不会向应用程序通知, 因此他被悄然执行了。

我们可以用更新后的邮件地址，使用常规的"I lost my password"链接 - 一分钟后就会受到这样的邮件：

1. From: [email protected] 
2. To: [email protected] 
3. Subject: Intranet login 
4.  
5. This email is in response to your request for your Intranet log in information. 
6. Your User ID is: bob 
7. Your password is: hello 

现在，就可以使用标准的登录流程进入系统，作为一个高等级的职员。这是一个高权限用户，远远高于我们INSERT创建的受限用户。

我们发现这个内网站点的信息比较全，甚至还有一个全用户列表。所以我们可以合理的推测很多内网站点会有公司Windows网络帐号，并且用的是同样的密 码。目前我们很明显可以拿到内网的用户密码，而且我们在公司防火墙找到了一个开放的PPTP模式的的VPN端口让我们很方便的做些登陆尝试。

我们手动抽查了一些帐号，没成功。而且不知道到底服务端是因为“错误的密码”还是“内网帐号和Windows帐号不同”而拒绝登陆的。反正就是个没干成。不过我嚼得自动化的工具应该能让这步简单点。

其他一些方法

在这次渗透中，我们觉得其实已经挖的足够深了，不过还可以用其他的方法。我们就先看看我们现在想到一些普适性不是很高的方法。

我们同时也注意到了不是所有的方法都是数据库无关的，有些方法得依赖特定的数据库。

调用XP_CMDSHELL

Microsoft的SQL Server 有一个存储过程 “XP_CMDSHELL” 允许执行任意的操作系统命令，如果这项功授权给Web用户调用的话，那基本上网站肯定会遭黑。我们现在干的都被限制在了Web应用和数据库这个环境下，一 旦能执行操作系统命令，防御再好的应用服务器也没辙了。调用这个存储过程的权限一般会赋给管理员帐号，但是还是存在授权给低级别用户的可能。

数据库结构深度挖掘

这个应用登陆后能干的事太多了，在我看来实在没啥必要再去挖了。不过在其他一些特殊的环境下我们的这些方法也许不够用。如果能深度挖掘数据库的结构，我们 会发现更多的方法来黑掉站点。你可以试着看看其他的提交切入点（例如“留言板”，“帮助论坛”等等）。不过这都是对应用环境的强依赖而且还得靠有一定技术 含量的瞎蒙。

减轻危害

我们相信web应用的开发者，通常不会去想那些“令人意外的输入”，但是安全人员会（包括那些“坏人”），所以这里有三个宽泛的方法，可以用来除害。

过滤输入，这是绝对重要的事情，过滤用户的输入，从而确保他们的输入没有包含具有威胁的代码，无论是对于SQL服务器，或则是HTML本身都要考虑。某人 最初的想法来剥掉“恶意代码”，例如引号，分号或者是转义符号，其实这种尝试是被误导了的。尽管找出来些具有威胁的字符很容易，但是很难把他们全部找到。 web的语言种到处都是特定的字符以及奇特的组合（包括那些用来表达同一些字符的另类模式），而努力去鉴定那些没有被授权的“恶意代码”很可能不会成功。 换而言之，与其“除去那些已知的恶数据”，倒不如“去掉所有良好数据之外所有的内容”：这其中的分别是至关重要。如前 － 我们的例子中 － 一个电子邮件地址仅能包括以下字符：

1. abcdefghijklmnopqrstuvwxyz 
2. ABCDEFGHIJKLMNOPQRSTUVWXYZ 
3. 0123456789 
4. @.-_+ 

用没有意义的文字是不益的，应该早点拒绝这么做，这可能会产生一些错误信息，这样不仅可以帮助我们抢先SQL注入，而且可以让我们及时发现拼写错误以至于不会让错误存入数据库。

我们应该要特别的注意邮件地址，它会给验证编程带来麻烦的，因为，每个人看起来对邮件地址的“有效性”都有自己的想法，不用一个好的邮箱地址是不光彩的，这样你将遇到你想不到的文字。

这方面的真正权威是RFC 2822(比大家耳熟能详RFC822内容还多)，里面包含了什么是允许的比较范的定义。如果邮箱地址接受&和*(和其它普通字符比较)是不好的，但是其它的，包括这篇文章的作者，都会对“大多数”邮件地址满意。

那些采用严格方法的人应该充分的认识到不包括这些邮件地址的后果，特别是认为现在有很好的技术能够解决那些“奇怪”的字符所带来的安全问题。

请注意“过滤输入”并不意味着“移除引号”，因为即使一个“正规”的字符也会很麻烦，在这个例子中，一个整型数字ID值被拿来和用户的输入做比较（叫数字型PIN）：

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

不过实际情况是我们很难把输入项完全过滤掉潜在危险字符。“日期项”，“邮件地址”，或者“整形” 用上面的办法过滤是可以的。但是在真实环境中我们，我们还得用到其他的方法。

输入项编码/转义

虽然现在可以过滤邮件地址或者电话号码，但是貌似“Bill O‘Reilly” 这样的合法的名字你是很难处理的，因为“ ’ ” 这个单引号是合法的输入。于是有人就想到在过滤到单引号的时候我再加一个单引号这样就没问题了，其实这么干得出大事。

1. SELECT fieldlist FROM customers 
2.  WHERE name = ‘Bill O‘‘Reilly‘;  -- 目前这样是OK的 

但是，这个方法很容易就被绕过去了。像MySQL允许 \‘ 这个输入，然后如果有人造一段SQL “ \‘; DROP TABLE users;” ,你又给单引号加了个单引号，那就变成

1. SELECT fieldlist FROM customers 
2.  WHERE name = ‘\‘‘; DROP TABLE users; --‘;  -- 删表了 

‘ \‘ ‘就被新加的单引号分成一个字符串(按照前面的过滤方法这里判断有一个单引号，所以过滤后再单引号后面加一个单引号)，后面接的是常见的SQL恶意代码。 其实不仅仅有反斜线的情况，还有Unicode编码和其他编码规则或者其他的过滤漏洞都会给程序员挖坑。俺们都知道，实现输入过滤的绝对安全是超级难滴， 这就是为啥很多数据库接口都提供了相关功能。当同样的内容被系统自带的字符串过滤或字符串编码处理后会好很多。例如调用MySQL的函数 mysql_real_escape_string() 或者 perl  DBD 的$dbh->quote($value)方法. 这些方法都必用的。