sql注入漏洞检测

一个分号就能让后台数据库彻底裸奔，入漏这事儿我亲眼见过。洞检

去年帮朋友排查他们公司的入漏订单系统，登录框输了个' or 洞检1=1 --，页面直接跳转到管理后台。入漏那感觉就像拿钥匙捅了下锁，洞检门自己开了。入漏更离谱的洞检是，他们IT主管还嘴硬说系统是入漏外包大厂做的，绝对安全——直到我把他数据库里所有用户表的洞检密码哈希导出来，他才闭嘴。入漏

SQL注入的洞检本质，说白了就是入漏程序把用户输入当成了代码执行。你往查询语句里塞点特殊字符，洞检数据库就分不清哪段是入漏命令、哪段是数据了。最常见的入口就是那些不带参数化的查询，比如拼接字符串：

SELECT * FROM users WHERE name = '"+input+"'

这种写法等于把数据库的枪交到用户手里。你输入admin'--，注释符把后面的条件全干掉，直接以管理员身份登录。更狠的还能用UNION SELECT把别的表数据拖出来，或者用xp_cmdshell直接执行系统命令——那就不是数据泄露的问题了，是服务器直接沦陷。

检测这东西，别迷信扫描器。sqlmap确实能自动跑，但真正难搞的是那些半吊子过滤。有次我测一个站点，参数里把or和and都过滤了，换成||和&&就绕过去了。还有的只过滤了单引号，那就用十六进制编码或者char()函数拼。你得像个侦探一样，先摸清对方过滤了什么、没过滤什么，再对症下药。

手工测的时候，最笨也最有效的办法是看报错。输入个'，如果页面弹出数据库语法错误，基本就实锤了。没报错也不代表安全，可能被统一异常处理吞掉了，那就试布尔盲注——条件真的时候页面正常，假的时候页面异常，一点点把数据猜出来。时间盲注更隐蔽，用sleep(5)看响应时间，慢五秒就是中招了。

我见过最气人的一种情况：开发人员把参数值用addslashes()转义了，但漏了数字型参数。那种不带引号的查询，比如WHERE id = 123，你直接拼123 AND 1=2，转义函数根本管不着——因为它只处理字符串，数字直接拼进去。这种坑，扫描器往往扫不出来，只能靠人工盯代码或者用代理工具改包测。

真要说防护，参数化查询是底线，不是选项。用PreparedStatement或者PDO绑定参数，用户输入永远只是数据，不是代码。其次是数据库权限收紧，别用sa或者root连应用，给个只读账号，就算被注入了也折腾不出水花。还有WAF做第二道闸，但别全指望它——规则总有漏网之鱼，而且攻击者天天在研究绕过。

说句实在话，SQL注入这毛病存在二十多年了，至今还是OWASP Top 10的常客。不是技术多高深，是人太懒、太自信。每次看到那些“我们系统经过等保三级”的客户，我就想笑——等保是合规，不等于安全。你拿个' or 1=1 --去试他们十个接口，能中两三个就算我输。

最后提个醒：检测的时候别拿生产库瞎搞，搞挂了数据你赔不起。本地搭个环境，或者用测试库，把日志关掉，IP换掉。真正的老手都懂得收着打，点到为止，验证存在漏洞就撤，别真把数据拖出来——那性质就变了。