前言

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