sql漏洞检测脚本

一个单引号就能让整个数据库裸奔，洞检这事儿我亲眼见过。测脚去年帮朋友排查一个电商后台，洞检登录框输入admin' or 测脚'1'='1，直接跳进了管理面板，洞检订单、测脚用户表、洞检支付记录，测脚全摊在那儿。洞检不是测脚他们倒霉，是洞检根本没做任何过滤。sql注入这玩意儿，测脚二十年前就被人玩烂了，洞检现在照样遍地都是测脚。

写个检测脚本，洞检其实不复杂。核心就三步：构造恶意payload，发请求，看响应特征。但别小看这三步，细节里全是坑。

先说我用的最笨也最有效的方法——基于报错的检测。往参数里塞'，如果数据库报错信息直接回显，比如You have an error in your SQL syntax，那基本就实锤了。但现在的站点普遍关了报错显示，这时候得换思路，用布尔盲注。payload改成' AND 1=1-- -和' AND 1=2-- -，对比两次响应长度、状态码或者页面关键字。差出几个字节，都算有戏。

写脚本的时候，别一上来就堆代码。先理清目标站点的参数位置。GET参数、POST表单、Cookie、甚至HTTP头里的Referer和X-Forwarded-For，都可能成为注入点。我见过一个奇葩案例，注入点在User-Agent里，因为后端把浏览器信息拼进了SQL查询，用来记录访问日志。你防住了表单，防不住头信息。

检测脚本要做得像个正常人，别一股脑狂发请求。加延时，随机化User-Agent，代理池轮换，这些都得考虑。否则你还没测出漏洞，先被WAF封了IP。我吃过这亏，某次测试一个政府站点，没控制频率，三分钟就被拉黑了，换了五个代理才缓过来。

响应判断这块儿，最容易出假阳性。有些站点对非法输入会统一返回500错误页，你发' AND 1=1和' AND 1=2都报错，那就没法区分。这时候得引入时间盲注，用SLEEP(5)或者BENCHMARK(10000000,MD5('a'))。如果请求响应时间明显超过5秒，基本能确定存在注入。但网络延迟会干扰判断，所以得设置阈值，比如超过4秒才算命中，连续测三次都这样才敢下结论。

脚本结构上，我习惯拆成模块。一个负责构造请求，一个负责发送，一个负责分析响应，再用个主控逻辑串起来。别把代码全堆在一个循环里，后续要加payload或者改检测策略，会改得想骂人。我早期写过一个三百行的单文件脚本，后来要支持post请求和cookie登录态，改得差点重写。

最后说点实在的。检测脚本不是一次性的，要定期更新payload库。数据库版本在变，防注入机制也在升级，比如现在很多框架默认就用参数化查询，传统拼接式注入已经没戏了。但二次注入、宽字节注入、order by注入这些变种，依然有生存空间。你得多看最新的漏洞报告，把新手法加进脚本里。

写脚本这活儿，三分靠技术，七分靠耐心。别指望一个脚本通杀所有站点，每个目标都可能给你点意外惊喜。但只要你把基础逻辑搞扎实了，遇到新情况能快速调整，那就够用了。毕竟，漏洞检测不是目的，找到问题、堵住漏洞才是。