数据库注入学习笔记7----宽字节注入

宽字节注入条件：

• 使用addslashes函数或是开启PHP的GPC
• 数据库编码为GBK，PHP编码为utf-8

宽字节注入原理：

• 例子php?id=1’,如程序没有报错，反而多了一个转义符（反斜杠）
• 参数id=1在数据库查询时是被单引号包围的。当传入id=1’时，传入的单引号又被转义符（反斜线）转义，导致参数ID无法逃逸单引号的包围，所以一般情况下，此处是不存在sql注入漏洞的。不过有一个特例，就是当数据库偏码为GBK时，可以使用宽字节注入，宽字节的格式是在地址后先加一个%df，在加单引号，因为反斜杠的编码为%5c，而在GBK编码中，%df%5c是繁体字“連”，所以这时，单引号成功逃逸，爆出mysql数据库的错误

操作：

• 由于输入的参数id=1’，导致sql语句多了一个单引号，所以需要使用注释符来注释程序自身的单引号。访问id=1%df%23，页面返回的结果已符合sql语法规范。
• 使用and 1 =1和and1 =2进一步判断注入，访问id=1%df’and 1=1 %23和id=1%df’and 1=2%23，当and 1 =1程序返回正常时，and 1=2 程序返回错误，所以判断该参数ID存在sql注入漏洞，接着使用order by查询数据库表的字段数量，最后得知字段数为3
• 因为页面直接显示了数据库中的内容，所以可以使用union查询。与uoion注入一样，此时uoion select 1,2,3,为了让页面返回uoion查询的结果，需要把ID的值改为负数，然后尝试在页面中2的位置查询当前数据库的库名（database（））,语句为：

id =-1%df'uoion select 1, user(),3,%23

• 查询数据库的表名是，一般使用一些语句：

select table_name from information_schema.tables where table schema='sql' limit 0,1

• 但是此时，由于单引号被转义，会自动多出反斜杠，导致sql语句出错，所以此处需要利用另外一种方法：嵌套查询。就是在一个查询语句中，再添加一个查询语句下列就是更改好的程序数据库表的语句：

select table_name from information_schema.table where table_schema = （select database() )limit 0,1

• 可以看到，原本的table_schema=‘sql’变成了table_schema=(select database()),因为select database()的结果就是’sql’，这就是嵌套查询，如返回结果数据库的第一个表名是emails，如果想查询后面的表名，还需修改limit后的数字，这里不再重复。使用以下语句尝试查询emails表里的字段：

select colun_name from information_schema.columns where table_schema =(select database()) and table_name =(select table_name from information_schema.tables where table_schema=(select databse())limit 0,1)linit 0,1

这里使用了三层嵌套，第一层是taable_schema，它代表库名的嵌套，第二层和第三层是table_name的嵌套。可以看到语句中有两个limit，前一个limit控制表名的顺序，后一个则控制字段名的顺序。如这里查询的不是emails表，而是users表，则需要修改limit的值，后面操作如union注入所示，这里不再重复。

代码分析：
在宽字节注入页面中，程序GET参数ID，并对参数ID使用addslashes()转义，然后拼接到sql语句中，进行查询，代码如下：

The Query string is : ".$sql.""
";
?>

当访问id=1’时,执行的sql语句为：

SELECT * FROM users WHERE id='1\"

• 可以看到单引号被转义符""转义，所以在一般情况下，是无法注入的，但由于在数据库查询前执行了SET
  NAMES’GBK’,将编码设置为宽字节GBK,所以此处存在宽字节注入漏洞。
• 在PHP中，通过iconv（）进行编码转换时，也肯存在宽字节漏洞。

总结：
不是所有的网站都存在宽字节注入，只有数据库设置编码为GBK，并且开启了魔术引号的才存在