【51CTO.com原创稿件】宽字节注入之前我看到过，但是没有实战过，后面也没有找到合适的测试环境，今天刚好看到一个关于宽字节注入的ctf题，因此借此来学习下宽字节注入，如果写得不好的地方，烦请各位多多指导!
本文主要是简单介绍下宽字节注入，以及如何通过手工和工具进行宽字节注入的一个利用，通过本文主要可学习到以下三点：
- 扩展了对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。
图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进行这些信息的获取。
图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所示。
图5 and也无法判断是否是注入点
难道是不存注入(肯定不是这样的)，那我们使用神器sqlmap盲跑试试，但是很失望，居然没有直接告诉我们有没有存在注入点，如图6所示。
图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所示：
图10 当前数据库有3列
我们看看我们将要查询的数据会在页面中哪些地方显示，如图11所示。
图11 查询在页面中显示的位置
到此，手工注入就结束了，后续操作请查看我的文章《mysql手工注入》的最后部分!
6. 宽字节sqlmap注入
在前面我们直接使用sqlmap盲跑，是没有发现该测试点是SQL注入点的，根据上面的特性，我们可以在id后面添加一个%81’，然后在使用sqlmap进行注入，注入语句为：
- sqlmap.py -u "http://103.238.227.13:10083/?id=1%81’" -b
这时，我们发现sqlmap可成功发现该注入点了，如图12所示。
图12 sqlmap成功检测出该注入点
除了上面的这种方法外，我们可以使用宽字节注入脚本来使用sqlmap进行注入，注入语句为：
- sqlmap.py -u "http://103.238.227.13:10083/?id=1" -b --tamper=unmagicquotes.py
这样我们也能成功探测出该注入点，如图13所示，对于后续的注入此处不再累赘!
图13 sqlmap成功检测出注入点
7. 简单修复建议
在初始化连接和字符集之后，使用SET character_set_client=binary来设定客户端的字符集是二进制的，另外对于服务器端返回的错误信息要么进行自定义，要么进行归一化的错误提示!
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
