宽字节注入之前看到过,但是没有实战过,后面也没有找到合适的测试环境,今天刚好看到一个关于宽字节注入的ctf题,因此借此来学习下宽字节注入,如果写得不好的地方,烦请各位多多指导,谢谢!本文主要是简单介绍下宽字节注入,以及如何通过手工和工具进行宽字节注入的一个利用,通过本文我主要学习到以下三点:
1、扩展了我对SQL注入进行探测的一个思路!
2、学习了如何使用宽字节探测注入!
3、如何使用sqlmap自动化对宽字节进行注入!
0x01 宽字节注入
这里的宽字节注入是利用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。
图1 将十进制129转换为十六进制
0x02 实验环境
本次实验环境如下:
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进行这些信息的获取。
图2 F12信息收集
0x03 SQL注入简单思路
今天学习到了一个SQL注入探测的一个简单思路,而不是说就简单的and或者or以及’进行探测,或者直接使用sqlmap的-b参数来进行探测(以前的我是这样的),因此可能错过了好几个亿。对SQL注入进行探测主要可根据以下思路来进行:
第一步: 简单使用and、or、’,判断是否有注入,不行接着加入一些自己创的语句简单判断(如order by看有没有报错等)!
第二步,如果第一步没有看到效果,可进行宽字节注入探测,输入%bf'(或者%81’),发现报错,存在宽字节注入!
第三步,如果上述两步都没有效果,可以接着但不限于http头注入探测(sqlmap的话使用—level参数进行设置),等等。
0x04 注入类型探测
SQL注入根据不同的标准有不同的分类,如根据参数类型可分为数值型注入、字符型注入,根据注入的位置可分为POST注入、GET注入、cookie注入等,而sqlmap则将注入分为基于布尔的盲注、基于时间的盲注、基于报错的注入、联合查询注入、堆查询注入,这里为了方便我将SQL分为宽字节注入和非宽字节注入(个人分类,没有依据)。
宽字节注入在实际渗透测试中也是存在的,只是很少很少,这次刚好看到一个宽字节注入的ctf,也顺便再认真学习写宽字节注入的一些基本知识。如图3,通过提示我们可知该题是一道字符型的注入。
图3 注入测试提示
既然是字符型的注入,那么我们可以使用’和and来进行简单的判断,该测试点是否是SQL注入点!通过使用’,我们无法判断是否存在注入,没有可供我们判断的信息,如图4所示。
图4 ‘无法判断是否是注入
我们结合and来进一步判断,但是依旧没有任何信息可供我们进行判断该测试点是否是注入点,如图5所示。
图5 and也无法判断是否是注入点
难道是不存注入(这肯定不是这样的),那我们使用神器sqlmap盲跑试试,但是很失望,居然没有直接告诉我们有没有存在注入点,如图6所示。
图6 sqlmap提示不像是注入
如果按照我以前的思路,我可能就已经放弃了,在实战中的话可能就认为真的不是注入点了(有点草率),此时我们使用思路的第二步来进行判断,该测试点是不是宽字节注入,我们使用ascii码的129(也即是%81,可以使用常使用的%df)进行探测,如图7所示,发现页面报错了,根据页面信息可判断该测试点存在SQL注入,并且是宽字节注入。
图7 判断注入是宽字节注入
0x05 宽字节手工简单注入
通过上面我们可知,该注入点是宽字节注入,且是字符型的注入,此时我们可通过构造SQL语句来进行SQL的宽字节注入,另外我们也可测试下我们输入的’是否被转义成为了\’,如图8所示,我们输入的’确实被转义了!
图8 '被转义了
此时我们可构造语句%81’ and 1=1---来进行注入,原因是’被转义成为\’,而%81的ascii码大于128,此时%81’就被看作一个字符(两个字节),此时’就可以使用了,而后面我们构造一个数值型的注入语句,最后再加注释把最后的那个’注释点,如图9所示。
图9 宽字节注入
此时我们使用order by来看看当前数据库有几列,发现数据库有三列,如图10所示
图10 当前数据库有3列
我们看看我们将要查询的数据会在页面中哪些地方显示,如图11所示。
图11 查询在页面中显示的位置
到此,手工注入就结束了,后续操作请查看我的文章《mysql手工注入》的最后部分!
0x06 宽字节sqlmap注入
在前面我们直接使用sqlmap盲跑,是没有发现该测试点是SQL注入点的,根据上面的特性,我们可以在id后面添加一个%81’,然后在使用sqlmap进行注入,注入语句为:
1
|
sqlmap.py -u
"http://103.238.227.13:10083/?id=1%81’"
-b
|
这是,我们发现sqlmap可成功发现该注入点了,如图12所示。
图12 sqlmap成功检测出该注入点
除了上面的这种方法外,我们可以使用宽字节注入脚本来使用sqlmap进行注入,注入语句为:
1
|
sqlmap.py -u
"http://103.238.227.13:10083/?id=1"
-b --tamper=unmagicquotes.py
|
这样我们也能成功探测出该注入点,如图13所示,对于后续的注入此处不再累赘!
图13 sqlmap成功检测出注入点
0x07 简单修复建议
就是在初始化连接和字符集之后,使用SET character_set_client=binary来设定客户端的字符集是二进制的,另外对于服务器端返回的错误信息要么进行自定义,要么进行归一化的错误提示!以上建议仅供参考!
本文转自 eth10 51CTO博客,原文链接:http://blog.51cto.com/eth10/1962804