热门关键字:   网站安全  黑客攻防  安全漏洞  系统安全  网络安全

黑客攻防之浅谈宽字节注入

发布时间:2017-10-10 17:29文章来源:网络文章作者:秩名 点击次数:
摘要:本文主要是简单介绍下宽字节注入,以及如何通过手工和工具进行宽字节注入的一个利用,通过本文主要可学习到以下三点: 扩展了对SQL注入进行探测的一个思路! 学习了如何使用宽字节探测注入! 如何使用sqlmap自动化对宽字节进行注入!...

1. 宽字节注入

这里的宽字节注入是利用MySQL的一个特性,MySQL在使用GBK编码(GBK就是常说的宽字节之一,实际上只有两字节)的时候,会认为两个字符是一个汉字(前一个ascii码要大于128,才到汉字的范围),而当我们输入有单引号时会自动加入\进行转义而变为\’(在PHP配置文件中magic_quotes_gpc=On的情况下或者使用addslashes函数,icov函数,mysql_real_escape_string函数、mysql_escape_string函数等,提交的参数中如果带有单引号’,就会被自动转义\’,使得多数注入攻击无效),由于宽字节带来的安全问题主要是吃ASCII字符(一字节)的现象,将后面的一个字节与前一个大于128的ascii码进行组合成为一个完整的字符(MySQL判断一个字符是不是汉字,首先两个字符是一个汉字,另外根据gbk编码,第一个字节ascii码大于128,基本上就可以了),此时’前的\就被吃了,我们就可以使用’了,利用这个特性从而可实施SQL注入的利用。

最常使用的宽字节注入是利用%df,其实只要第一个ascii码大于128就可以了,比如ascii码为129的就可以,但是我们怎么将他转换为URL编码呢?其实很简单,我们先将129(十进制)转换为十六进制,为0x81,如图1所示,然后在十六进制前面加%即可,即为%81,任意进制在线转换网站请点击此处!另外可以直接记住GBK首字节对应0×81-0xFE,尾字节对应0×40-0xFE(除0×7F),则尾字节会被吃点,如转义符号\对应的编码0×5C!另外简单提一下,GB2312是被GBK兼容的,它的高位范围是0xA1-0xF7,低位范围是0xA1-0xFE(0x5C不在该范围内),因此不能使用编码吃掉%5c。

将十进制129转换为十六进制

图1 将十进制129转换为十六进制

2. 实验环境

本次实验环境如下:

URL地址:http://103.238.227.13:10083/

相关版本信息:

  • PHP 7.0.7、mysql 5.5.48-log!
  • WebServer: nginx!
  • Content-Type: text/html; charset=gbk!

以上多数信息可使用F12进行简单的信息收集(近期我正在将我目前会的渗透实战中常用的信息收集进行整理,其中第一个信息收集就是F12信息收集),通过F12我们收集到如图2所示信息,另外我们也可通过添加火狐插件server-spy进行这些信息的获取。

F12信息收集

图2 F12信息收集

3. SQL注入简单思路

今天学习到了一个SQL注入探测的一个简单思路,而不是说就简单的and或者or以及’进行探测,或者直接使用sqlmap的-b参数来进行探测(以前的我是这样的),因此可能错过了好几个亿。对SQL注入进行探测可根据以下思路来进行:

第一步: 简单使用and、or、’,判断是否有注入,不行接着加入一些自创的语句进行简单判断(如order by看有没有报错等)!

第二步,如果第一步没有看到效果,可进行宽字节注入探测,输入%bf'(或者%81’),发现报错,存在宽字节注入!

第三步,如果上述两步都没有效果,可以接着但不限于http头注入探测(sqlmap的话使用—level参数进行设置),等等。

4. 注入类型探测

SQL注入根据不同的标准有不同的分类,如根据参数类型可分为数值型注入、字符型注入,根据注入的位置可分为POST注入、GET注入、cookie注入等,而sqlmap则将注入分为基于布尔的盲注、基于时间的盲注、基于报错的注入、联合查询注入、堆查询注入,这里为了方便我将SQL分为宽字节注入和非宽字节注入(个人分类,没有依据)。

宽字节注入在实际渗透测试中也是存在的,只是很少很少,这次刚好看到一个宽字节注入的ctf,也顺便再认真学习写宽字节注入的一些基本知识。如图3,通过提示我们可知该题是一道字符型的注入。

注入测试提示

图3 注入测试提示

既然是字符型的注入,那么我们可以使用’和and来进行简单的判断,该测试点是否是SQL注入点!通过使用’,我们无法判断是否存在注入,没有可供我们判断的信息,如图4所示。

‘无法判断是否是注入

图4 ‘无法判断是否是注入

我们结合and来进一步判断,但是依旧没有任何信息可供我们进行判断该测试点是否是注入点,如图5所示。

and也无法判断是否是注入点

图5 and也无法判断是否是注入点

难道是不存注入(肯定不是这样的),那我们使用神器sqlmap盲跑试试,但是很失望,居然没有直接告诉我们有没有存在注入点,如图6所示。

sqlmap提示不像是注入

图6 sqlmap提示不像是注入

如果按照我以前的思路,我可能就已经放弃了,在实战中的话可能就认为真的不是注入点了(有点草率),此时我们使用思路的第二步来进行判断,该测试点是不是宽字节注入,我们使用ascii码的129(也即是%81,可以使用常使用的%df)进行探测,如图7所示,发现页面报错了,根据页面信息可判断该测试点存在SQL注入,并且是宽字节注入。

判断注入是宽字节注入

图7 判断注入是宽字节注入

5. 宽字节手工简单注入

通过上面的说明,我们可知该注入点是宽字节注入,且是字符型的注入,此时我们可通过构造SQL语句来进行SQL的宽字节注入,另外我们也可测试下我们输入的’是否被转义成为了\’,如图8所示,我们输入的’确实被转义了!

‘被转义了

图8 ‘被转义了

此时我们可构造语句%81’ and 1=1-- -来进行注入,原因是’被转义成为\’,而%81的ascii码大于128,此时%81’就被看作一个字符(两个字节),此时’就可以使用了,而后面我们构造一个数值型的注入语句,最后再加注释把最后的那个’注释掉,如图9所示。

宽字节注入

图9 宽字节注入

此时我们使用order by来看看当前数据库有几列,发现数据库有三列,如图10所示:

当前数据库有3列

图10 当前数据库有3列

我们看看我们将要查询的数据会在页面中哪些地方显示,如图11所示。

查询在页面中显示的位置

图11 查询在页面中显示的位置

到此,手工注入就结束了,后续操作请查看我的文章《mysql手工注入》的最后部分!

6. 宽字节sqlmap注入

在前面我们直接使用sqlmap盲跑,是没有发现该测试点是SQL注入点的,根据上面的特性,我们可以在id后面添加一个%81’,然后在使用sqlmap进行注入,注入语句为:

  1. sqlmap.py -u "http://103.238.227.13:10083/?id=1%81’" -b 

这时,我们发现sqlmap可成功发现该注入点了,如图12所示。

sqlmap成功检测出该注入点

图12 sqlmap成功检测出该注入点

除了上面的这种方法外,我们可以使用宽字节注入脚本来使用sqlmap进行注入,注入语句为:

  1. sqlmap.py -u "http://103.238.227.13:10083/?id=1" -b --tamper=unmagicquotes.py 

这样我们也能成功探测出该注入点,如图13所示,对于后续的注入此处不再累赘!

sqlmap成功检测出注入点

图13 sqlmap成功检测出注入点

7. 简单修复建议

在初始化连接和字符集之后,使用SET character_set_client=binary来设定客户端的字符集是二进制的,另外对于服务器端返回的错误信息要么进行自定义,要么进行归一化的错误提示!

标签分类:

上一篇:主动欺骗蜜罐系统Beeswarm简介
下一篇:那些年我们看不懂的XSS