码迷,mamicode.com
首页 > 数据库 > 详细

SQL注入(二)

时间:2015-05-07 00:47:53      阅读:177      评论:0      收藏:0      [点我收藏+]

标签:

5.限制输入长度  

  如果在Web页面上使用文本框收集用户输入的数据,使用文本框的MaxLength属性来限制用户输入过长的字符也是一个很好的方法,因为用户的输入不够长,也就减少了贴入大量脚本的可能性。程序员可以针对需要收集的数据类型作出一个相应的限制策略。

6.URL重写技术

        我们利用URL重写技术过滤一些SQL注入字符,从而达到防御SQL注入。因为许多SQL注入是从URL输入发生的。

7.传递参数尽量不是字符

  假设我们显示一篇新闻的页面,从URL传递参数中获得newid我们可能会随手写下下面的代码:   

  string newsid = Request.QueryString["newsid"];
  string newssql = "select * from news where newsid=" + newsid;

 

 

  如果传递过来的参数是数字字符就没有问题。但是如果传递过来的newsid是“1 delete from table ”的话,那么sql的值就变成了“select * from table where newsid=1 delete from news”。发生注入成功。但是这里改为

        int newsid=int.Parse(Request.QueryString["newsid"].ToString());

        string newssql = "select * from news where newsid=" + newsid.Tostring();

        这里如果还是上面"1 delete from table "会发生错误,因为在转换时候出现了错误

        从上面的一个小例子,我们得出在传递参数时候尽量不要用字符,免得被注入。 

 

  最后是我想扩展下利用URL重写技术来过滤一些SQL注入字符,首先这里有一篇关于URL重写的文章,我的基本思想是可以利用它,屏蔽一些危险的SQL注入字符串,这些字符串我们可以人为的设定,毕竟我们还是根据特定的环境设定我们防御措施。首先我们在ModuleRewriter类中的Rewrite函数得到绝对的URL判断其中是否有危险字符,如果有我们就将它链接到一个提示用户您输入危险的URL地址。如果不是我们继续判断是否触发了其他的URL重写的规则,触发了就重写。这样就大致上能在URL上防御危险字符

代码

 

上面是要在web.config配置文件加上的内容,这里我加上了两个重写规则,第一个规则是专门针对满足这个正则表达式的页面URL查看是否有危险字符,有危险字符就会发送到Default_sql_error.aspx页面,来示警。这里我假定会发生危险字符注入的页面时以"d"字符开头并加上数字的页面(这里我们可以根据实际情况自己定义,看哪些页面URL容易发生我们就制定这些页面的正则表达式),第二个是一般URL重写。因为这里我采用的是HTTP模块执行URL重写,所以加上<httpModules></httpModules>这一块。

         第二步就是要在重写Rewrite函数了

 

 
protected override void Rewrite(string requestedPath, System.Web.HttpApplication app)
{
// 获得配置规则
RewriterRuleCollection rules = RewriterConfiguration.GetConfig().Rules;

Uri url = app.Request.Url;

// 判断url 中是否含有SQL 注入攻击敏感的字符或字符串,如果存在,sqlatFlag = 1 ;
string urlstr = url.AbsoluteUri;
int sqlatFlag = 0;
string words = "exec ,xp ,sp ,declare ,cmd ,Union ,--";

// 如果还有其他敏感的字符或者符号,可以加入上面这行字符串中
string[] split = words.Split(‘,‘);
foreach (string s in split)
{
if (urlstr.IndexOf(s.ToUpper()) > 0)
{
sqlatFlag = 1;
break;
}
}
if (sqlatFlag == 1)
{
// 创建regex
Regex re = new Regex(rules[0].SendTo, RegexOptions.IgnoreCase);
// 找到匹配的规则,进行必要的替换
string sendToUrl = RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, re.ToString());
// 重写URL
RewriterUtils.RewriteUrl(app.Context, sendToUrl);
//RewriterUtils.RewriteUrl(app.Context, rules[0].SendTo);
}
else
{
// 遍历除rules[0 ]以外的其他URL 重写规则
for (int i = 1; i < rules.Count; i++)
{
// 获得要查找的模式,并且解析URL (转换为相应的目录)
string lookFor = "^" + RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, rules[i].LookFor) + "$";
// 创建regex
Regex re = new Regex(lookFor, RegexOptions.IgnoreCase);
// 查看是否找到了匹配的规则
if (re.IsMatch(requestedPath))
{
// 找到了匹配的规则, 进行必要的替换
string sendToUrl = RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, re.Replace(requestedPath, rules[i].SendTo));
// 重写URL
RewriterUtils.RewriteUrl(app.Context, sendToUrl);
break;
// 退出For 循环
}
}
}
}
 

 

 

那么下一步就是检验例子了

首先我们输入http://localhost:4563/web/Default.aspx?id=1;-- 

这样http://localhost:4563/web/Default.aspx?id=1;-- 没有改变,就会显示Default_sql_error.aspx里内容“您输入了危险字符”。 
再输入http://localhost:4563/web/D11.aspx就会显示 Default2.aspx内容,因为这里触发了第二个重写规则

 试验成功。

  当然用URL防SQL只是我想到一种怪癖思路,大家如果有什么特别方法可以共同考论一下,还是引用前辈们话“见招拆招”遇到实际的问题我们就根据实际情况解决,选用那个最实用的方法。

 

 

 

一个客户对我们请求说,请我们来检查一下他的内部网络,这个网络被公司的职员以及客户们来使用。这是一个较大的安全评估的一部分,而且,虽然我们以前从没 有真正的使用过SQL注入来破解一个网络,但是我们对于其一般的概念相当的熟悉。在此次“战斗”中,我们是完全成功的,而且想要通过把这个过程的每一个步骤重新记录下来,并作为一个“生动的例子”。

“SQL注入”是特定的一种未被确认或未明确身份的用户输入漏洞的一个子集(“缓冲溢出”是一个不同的子集),而这个想法的目标是,让应用程序确信从而去 运行SQL代码,而这些代码并不在其目的之内。如果一个应用程序是在本地通过即时的方式来创建一个SQL字符串,结果很直接,会造成一些真正的出人意料的结果。

我们要明确说明的是,这是一个有些曲折的过程,并且其中会有多次的错误的转折,而其余的更有经验的人当然会有着不同的-甚至更好的-方法。而事实上,我们成功的实现了建议,并没有被完全的误导。

还有一些不同的论文讨论SQL注入问题,包括一些更加详细的文章,不过此文所展示的,与破解的过程同样份量的是发现了SQL注入的原因。

目标内网

这显然是一个完全自主开发的应用程序,而我们对于它没有预先的了解,或者访问源代码的权限:这已是一个“blind”攻击。若干次侦测之后,我们了解到服 务器运行的是微软的IIS6,并使用ASP.NET框架,从这其中得到的,似乎可以假定数据库是微软的SQL服务器:我们相信这些技术可以应用于几乎任何 一种web应用,而此应用可能为任何一种SQL服务器所支持。

登陆页面是一个传统的用户名-密码表单,带有一个用电子邮件给我传送密码的链接;而后者被证实是整个系统的败笔。

当输入一个电子邮件地址的时候,系统会假定次邮件存在的方式,再用户数据库里面寻找这个电子邮件地址,并且会邮寄一些内容到这个地址。由于我的电子邮件地址没有被找到,所以它不会给我发送任何内容。

所以,第一个测试,对于任何SQL化的表单而言,是输入一个带有单引号构成的数据:这样做的目标是查看是否他们在构建SQL字符串的时候根本没有使用数据 的清理机制。当为此表单提交了一个有单引号的电子邮件之后,我们得到了一个500错误(服务器失败),这就是说,这个“被破坏了的”的输入实际上被真实的 分析过。中!

我们猜测底层的SQL代码可能类似于如此:

  1. SELECT fieldlist FROM table WHERE field = ‘$EMAIL‘; 

这里,$EMAIL是由用户通过表单提交的电子邮件地址,而这段较长的查询提供的应用符号,是为了使得这个$EMAIL成为一个真正的字符串。我们不知道 这个数据域的确切的名字或者是于此相关的数据表的名字,但是我们却了解他们的特性,而此后我们将会得到一些很好的猜测结果。

当我们输入steve@unixwiz.net‘ - 留意那个结尾的引号 - 这将产生出一个如下构建的SQL:

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

当这个SQL被执行的时候,SQL分析器发现了多余的引号,从而中止了工作,并给出一个语法错误。而这个错误如何表述给用户,取决于应用程序内部错误修复 的过程,但是这通常不同于“电子邮件地址不存在”的错误提示。这个错误的响应是致命的第一通道,既用户的输入没有被正确的清理,而因此应用程序成为了破解 的美食。

由于我们输入的数据显然位于WHERE子语句中,让我们用合法的SQL方式改变一下这个子句的本貌并看看会发生什么。通过输入任何一种‘OR ’x‘=x语句,结果SQL成为:

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

因为应用程序没有真正的对这样的查询有所考虑,而仅仅是构建一个字符串,以致于我们使用的引号使得一个单元素的WHERE子句,变成了一个双元素的子句, 而且’x‘=x字句是确定为真的,无论第一个字句是什么。(有一种更好的方式来确保“始终为真”,这部分我们后面会谈及)

不过与“真实”的查询不同,本应当一次返回一个单独的项,这个版本必然会返回成员数据库里面的每一个项。唯一的可以发现应用程序在这种情况下会做什么的方式,就是尝试。不断尝试,我们留意到以下结果:

你的登录信息已经发送到 random.person@example.com.

我们一般都会把查询返回的第一行作为作为猜测的主要入口。这哥们确实从E-mail里拿回了他的密码,同样这个邮件可能会让他感到吃惊并且会引起怀疑。

现在我们知道怎么在本地玩这条查询了,虽然目前我们还不知道我们看不到的那部分SQL结构是怎么拼起来的。但是我们通过逆向工程看到了三个不同的查询结果:

  • 您的登陆信息已经以Email形式发送给您
  • 我们无法识别您的Email地址
  • 服务端错误

头两个响应是有效的查询的结果,最后一个是无效SQL造成的。 类似这样的响应结果会帮助我们更好的逆推服务端用来查询的SQL语句结构。

预设字段映射

我们要干的第一步就是猜字段名,首先我们合理的推测查询带了“email address” 和 “password”,所以可能的字段名选择会有“US Mail Address”  或者 “userid” 亦或者“phone number”  。当然最好能执行 show table,但是我们又不知道表名,貌似目前没什么明显的方法能让我们拿到表名。

那就分步走吧。在每个例子里,我们会用我们已知的SQL加上我们自己的特殊“段”。我们已知的这条SQL的结尾是个Email地址的比对,那就猜下email是这个字段名吧

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

如果服务器响应是报错,那基本上可以说明我们的SQL拼错了。但是如果我们得到任何正常的返回,例如“未知的邮件地址” 或 “密码已发送”  ,说明我们的字段名蒙对了。

要注意的是,我们的“And” 关键字而没用“OR” 关键字,这么做是有目地滴。在上一步中,我们不关心到底是哪一个Email,而且我们不想因为蒙中某人的Email然后给他发了重置密码的邮件。这么搞那 哥们儿一定会怀疑有人对他的帐号搞三搞四。所以用“And”关键字拼上一个不合法的Email地址,这样服务端总是返回空结果集,也就不会给任何人发邮 件。

提交上面的SQL代码段确实返回了“未知的邮件地址” 这么一个响应。现在我们确认了email地址的字段名是email。如果不是这么个响应,那我就再蒙“email_adress”或者“mail”亦或者 其他类似的。这个环节总是靠蒙的,但是蒙也得讲技巧和方法方式。

这段SQL的用意是我们假设预设的SQL查询中的字段名是 email ,跑一下看看是不是有效。我不会管你到底有没有匹配的Email,所以用了个伪名“x” , “--” 这个标示是表示SQL的起始。这样SQL解析到这就会把它直接当成一条命令,而“--”后面的会是一个新的命令,这样就屏蔽掉了后面的那些不知道的玩意 儿。

下一步,我们来猜下其他比较明显的字段名: "password","userid","name" 和类似的。每次我们只蒙一个名字,当返回结果不是“服务端错误” , 那就说明我们蒙对了。

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

通过这一步,我们蒙出来了下面几个字段名:

  • email
  • passwd
  • login_id
  • full_name

肯定还有更多其他的(把HTML页面表单的 <Input   name="XXXXX"> 拿来做参考是个非常不错的选择)后来我又挖了一下但是没挖出来更多的字段名。 到目前为止,我们还是不知道这些字段所属的表的表名--咋个弄呢?

搜寻表名

应用内建的query已经把表名放在语句中,但我们不知道表的名字。有几种方法可以找到这些插入在语句中表名(以及其他的表名)。我们用的是一种依赖于subselect的方法。

下面这个单独的query

  1. SELECT COUNT(*) FROM <i>tabname</i> 

返回表中记录的数量,当然,若表名是无效的,则查询失败。我们可以把这个查询放入我们的查询语句中来探查表名。

  1. SELECT email, passwd, login_id, full_name 
  2.   FROM <i>table</i> WHERE <b>email</b> = ‘<span>x‘ AND 1=(SELECT COUNT(*) FROM <i>tabname</i>); --‘</span>; 

我们实际上并不关心表中有多少记录,我们关心的是表名是否有效。通过试探不同的猜测,我们最终确定members是数据库中的有效表名。但是,这是这个查 询中所用的表名吗?为此,我们需要另一个使用table.field的查询:这只在表名的确是查询中的表名时才工作,而不仅仅当表存在时工作。

  1. SELECT email, passwd, login_id, full_name 
  2.   FROM members 
  3.  WHERE email = ‘<span>x‘ AND members.email IS NULL; --</span>‘; 

当这个语句返回 "Email unknown"时,可以确认我们的SQL正确执行了,并且我们成功的猜出了表名。这对后面的工作很重要,但我们先临时使用一下另一种方法。

弄几个帐号先

目前我们搞到了members表结构的部分信息,但是我们只知道一个用户名,就是之前我们蒙中的那个发了邮件通知的那个用户名。当时我们只得到了邮件地址,但是拿不到邮件内容。所以我们得再弄几个有效得用户名,高端洋气上档次的最好。

我们的从公司的网站开始人肉,找到那些人物介绍的页面,一般都是介绍公司内部人员的。这些介绍里大多都有这些人的Email地址和名字。就算没有这些信息也没啥,咱兜里还有货。

思路是这样的,提交一个带有“Like” 关键字的SQL,这样我们可以对Email地址或者用户名做些模糊匹配,每次提交如果返回“我们已发送您的密码至邮箱”那也就是说我们的模糊查询有效了,而且邮件也真的发了!!!。这么干虽然我们能拿到邮件地址,也意味着对方会收到邮件并引起警觉,所以  慎用!!

我们能做email、full_name(或者其他字段)的查询,每次放入%这个通配符执行如下的查询:

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

暴力破解密码

我们肯定可以在登陆页面尝试暴力破解密码,但是大多的应用都做了相应的防护手段。可能的防护会有操作日志,帐号锁定或者其他能大大降低我们效率的手段或设备,但是因为输入没有被过滤所以给我们绕过这些防护多了一些可能。

我们将把密码和邮件名称的代码段加到我们已知的SQL里。在这个例子里我们会用一个倒霉催的哥们的邮箱,bob@example.com 然后试试我们准备的一些密码。

  1. SELECT email, passwd, login_id, full_name 
  2.   FROM members 
  3.  WHERE email = ‘bob@example.com‘ AND passwd = ‘hello123‘; 

这条SQL是完整有效的,所以服务器铁定不能够报错,所以我们知道当服务器响应是“您的密码已经发送至您的邮箱” 这么个结果是我们就知道刚提交的那个密码就是我们要的密码。虽然倒霉催的Bob也收到了邮件并且一定会警觉,但是我们在他警觉之前就干完我们想干的了。

这个过程可以在Perl下用脚本自动化完成,所以我们就去搞了搞Perl的脚本,结果写脚本的时候发现了另外一种方法来干这事。

数据库不是只读的

迄今为止,我们对数据库除了进行查询外,没做其他事。尽管SELECT是只读的,但不意味SQL就只能这样。SQL使用分号来中断一个语句, 如果对输入没有做正确的处理, 它就不能阻止我们在查询语句后面添加不相关的字符串。

最恰当的一个例子就是这样:

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

第一部分提供了一个假的邮件地址 -- ‘x‘ -- 我们并不关系这个查询的返回,我们仅仅是给出了一个我们能够使用无关SQL指令的方式,一个尝试删除整个members表而真的是无任何关系的操作.

这表明我们不仅仅可以切分SQL指令,我们还可以修改数据库,这完全是被允许的。

加入一个新成员

由上所得,我们获知了members表的部分的结构,尝试添加一个新的记录到这个表里面似乎是一个可拊掌称庆的方法:如果这能成功,我们就能够通过我们新插入的帐户来直接登陆了。

这里,毫不惊奇的是,这只需要稍微加些SQL,我们把它放在不同的行从而让我们的展示更易理解,不过从头到尾这一部分其实仍然是一个字符串:

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‘);--‘; 

即便是我们真的确定了表的名字以及使用的字段都是正确的,在成功的实施攻击之前,仍然有一些障碍:

  1. 可能,在表单上,我们并没有足够的空间来直接输入这些文本(尽管,可以使用脚本来解决这个问题,而这并不是很简便的事情)
  2.  web应用程序的用户可能并没有在members表上的插入权限。
  3.  毫无疑问,members表里面有一些别的字段,有一些可能需要初始化的数据,而这可能导致插入失败。
  4.  即便是可以达到插入一个新的记录,应用程序可能会出现不当的行为,因为自动插入的时候有一些字段使用的是NULL。
  5.  一个有效的“成员”可能不仅仅需要在members表里面的一个记录,而是和别的表有着数据上的关联,(如,“访问权限”),所以添加一个数据到一个表中,可能并不充分有效。

对于手头的案例而言,我们遇到了#4或者是#5上面的障碍 - 我们无法真正确定是哪一个 - 因为在主登陆界面上,输入上面的用户名+密码的时候,返回了一个服务器上的错误。这就是说,那些我们没有用到的字段可能是必要的字段,而尽管如此,它们仍 然没有被正确的处理。

这里,一个可行的方法,就是猜测别的字段,但是这可以保证是一个长时间而且耗费劳力的过程:虽然你可能可以猜测出来那些“显而易见”的字段,但是却很难构建出整个应用程序的组织图像。

所以,最后我们选择走另一条不同的路。

SQL注入(二)

标签:

原文地址:http://www.cnblogs.com/barrywxx/p/4483621.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!