宽字节注入简介
背景:
尽管现在呼吁所有的程序都使用unicode编码,所有的网站都使用utf-8编码,来一个统一的国际规范。但仍然有很多,包括国内及国外(特别是非英语国家)的一些cms,仍然使用着自己国家的一套编码,比如我国的gbk,作为自己默认的编码类型。也有一些cms为了考虑老用户,推出了gbk和utf-8两个版本(例如:dedecms)
编码简介:
我们就以gbk字符编码为例,拉开帷幕。GBK全称《汉字内码扩展规范》,gbk是一种多字符编码。他使用了双字节编码方案,因为双字节编码所以gbk编码汉字,占用2个字节。一个utf-8编码的汉字,占用3个字节。
例如:0xD50x5C 对应了汉字“誠”,URL编码用百分号加字符的16进制编码表示字符,于是 %d5%5c 经URL解码后为“誠”。
什么是宽字节注入?
前面讲到了GBK编码格式。GBK是双字符编码,那么为什么他们会和渗透测试发送了“巧遇”呢?
宽字节SQL注入主要是源于程序员设置数据库编码为非英文编码那么就有可能产生宽字节注入
例如说MySql的编码设置为了SET NAMES 'gbk'或是 SET character_set_client =gbk,这样配置会引发编码转换从而导致的注入漏洞。
宽字节注入原理
根本原因:
宽字节注入就是PHP发送请求到MySql时使用了语句
SET NAMES 'gbk' 或是SET character_set_client =gbk 进行了一次编码,但是又由于一些不经意的字符集转换导致了宽字节注入
引入知识:
引入一个PHP的防御函数==>>magic_quotes_gpc(魔术引号开关)
magic_quotes_gpc函数在php中的作用是判断解析用户提交的数据,如包括有:post、get、cookie过来的数据增加转义字符“\”,以确保这些数据不会引起程序,特别是数据库语句因为特殊字符引起的污染而出现致命的错误。
单引号(’)、双引号(”)、反斜线(\)与 NULL(NULL 字符)等字符都会被加上反斜线
宽字节概念引入:
开启魔术引号之后,在注入点后面添加单引号的查询语句如下
SELECT * FROM users WHERE id='1\'' LIMIT 0,1
这条语句因为\使我们无法去注入,为了绕过magic_quotes_gpc的\,于是乎我们开始导入宽字节的概念
我们发现\的编码是%5c,然后有一个‘運’字引入我们的眼帘,根据gbk的编码,‘運’字是%df%5c,那么我们是不是可以用%df吃到%5c,因为如果用GBK编码的话这个就是運,然后就可以吃掉原来的转移符号。
输入%df'后,在SQL中的查询语句如下
SELECT * FROM users WHERE id='1�\'#' LIMIT 0,1
�\ 实际上就是那个運字,不仅仅%df可以,任何包含%5c的gbk编码字都可以,具体参考链接:https://www.qqxiuzi.cn/zh/hanzi-gbk-bianma.php
注入实现
此处用到靶场,打开靶场所在url,如下
判断注入点:
输入单引号进行测试,发现页面正常返回,SQL语句中出现了转义字符,如下
在单引号前面添加%df,观察页面变化,如下
闭合原有语句,如下
其余步骤:
其他步骤与联合查询显错注入、盲注类似
注意:
此处后面查询表名或者数据的时候需要用到,类似where table_schema='test'的代码,这里的test两边的单引号也会被转义,这里可以使用16进制编码绕过,test是字符串,十六进制编码之后也是字符串。
编码只能替换字符串,或者后台进行过解码的关键字,否则编码之后只是字符串,无法绕过,没有什么实际意义
自动化工具
sqlmap:
可以直接使用sqlmap跑,
--threads 10 //如果你玩过 msfconsole的话会对这个很熟悉 sqlmap线程最高设置为10
--level 3 //sqlmap默认测试所有的GET和POST参数,当--level的值大于等于2的时候也会测试HTTP Cookie头的值,当大于等于3的时候也会测试User-Agent和HTTP Referer头的值。最高可到5
--risk 3 // 执行测试的风险(0-3,默认为1)risk越高,越慢但是越安全
----search //后面跟参数 -D -T -C 搜索列(S),表(S)和或数据库名称(S)
sqlmap -u "http://xxx.xxx.xx.xx/xxx.php?id=1%df%27" --level 3 --threads=5 --risk 3 --delay 2 --random-agent
暂时这些吧