前言
由于最近一直在学习sql注入相关的知识,所有就像找一些网页挖挖漏洞,练练手。因为这是我第一次实战挖洞,也不太熟练,导致整个挖洞的过程太曲折了,太难受了。最后虽然找到了一个有sql注入漏洞的页面,但是由于其过滤比较严格,没有能实质性的脱出数据。只是可以利用堆叠注入进行数据库名枚举,好像并没有什么卵用。
挖洞实在是太难了。。。。呜呜呜呜
实战过程
发现阶段
在网上看到了一篇文章,讲如何实战挖洞,并在文章中附上了一些挖sql注入漏洞的要使用搜索语法。
https://bbs.zkaq.cn/t/5056.html
我就按照文章中的搜索语法依次进行百度搜索,然后在搜到的页面中进行sql注入检测
这是一个漫长的过程,一个一个页面的检测,真的太磨性子了。
过了很久很久终于找到了一个可能存在sql注入漏洞的页面。
使用”?id=6006 and 1=1″进行检测,得到返回页面如下
再使用“id=6006 and 1=2″进行检测,得到返回页面如下
WoCao,这不就是sql注入漏洞嘛
注入阶段
既然发现了注入点,就别怪我不客气啦。。。
先使用逗号让其报个错,”id=6006’“,返回结果如下
啊!!
怎么是一个SQL Server数据库啊,我平时都练的是MySQL数据库注入,这下完犊子了。找一篇SQL Server注入的文章看看呗。
https://blog.csdn.net/qq_36119192/article/details/88679754
看完觉得,其实和mysql注入差不多,继续玩呗。
A计划:
我第一个想到的攻击方法就是UNION联合注入攻击,那就开始呗。
第一步:”order by n” 查具有多少列
可以确定为32列,这也太简单了吧,嘿嘿嘿!!!
第二步:确定数据返回位置,语句如下:
”id=-6006 union select 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32“
路径未找到,难道是对输入进行了过滤?
我试一试。
第三步:确定过滤参数
只是爆出了,“union” 附近存在语法错误,表示并没有过滤”union“,再试一试”select“。
看来,还真是把”select”给过滤了,那我精明的小算盘就打错了,Cao!!!
看来只能想办法进行绕过了。还好我看来一些关于绕过sql限制的文章。
第四步:进行”select”限制绕过
使用了,过滤空格,内联注释,大小写,URL编码,URL二次编码,CHAR()编码,HEX()编码,双关键字等一系列方法进行绕过,都没有成功。
唉,人生不易啊,太难了。过滤的实在是太严格了,没有办法绕过,放弃了。
开始实施B计划。
B计划:
这真的是一个特别鸡肋的利用,没有什么用–使用堆叠注入进行数据库名的枚举。
第一步:进行手工检测,该漏洞是否存在
“msdb”数据库是SQL Server数据库中默认的数据库,其必然存在。
而对于名为”text“的数据库,返回页面爆出来数据库”text“不存在。
可以自己些一个python脚本,或者使用burp中的intruder模块,再加上一个常用数据库名字典,就可以枚举出该网站所使用的数据库名,但这好像并没用什么利用价值,我就没有继续向下进行了。
C计划:
使用sqlmap扫一下。
第一步:使用wafw00f扫一下,看该网站有没有使用WAF
结果显示,其可能在waf后面,也有可能是在一下安全策略后面。
经过前面的检测,我觉得其在waf后面的概论比较小
第二步:直接使用sqlmap进行扫描
但sqlmap扫描也没有爆出什么比较有价值的信息。
总结
唉,这次sql注入玩的实在是不爽!!!看来还要继续努力,好好学习,加油!!
来源:freebuf.com 2021-05-07 16:40:41 by: hu666666
请登录后发表评论
注册