浅谈对宽字节注入的认识

宽字节注入之前看到过，但是没有实战过，后面也没有找到合适的测试环境，今天刚好看到一个关于宽字节注入的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进行注入，注入语句为：

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

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

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

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

图13   sqlmap成功检测出注入点

0x07   简单修复建议

就是在初始化连接和字符集之后，使用SET character_set_client=binary来设定客户端的字符集是二进制的，另外对于服务器端返回的错误信息要么进行自定义，要么进行归一化的错误提示！以上建议仅供参考！

本文转自 eth10 51CTO博客，原文链接:http://blog.51cto.com/eth10/1962804