记一次不愉快的SQL注入实战经历
2021-05-07 17:40:41 Author: www.freebuf.com(查看原文) 阅读量:148 收藏

前言

由于最近一直在学习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注入玩的实在是不爽!!!看来还要继续努力,好好学习,加油!!


文章来源: https://www.freebuf.com/articles/web/272116.html
如有侵权请联系:admin#unsafe.sh