sql注入漏洞渗透测试

凌晨两点，入漏我盯着Burp Suite里那条红色的洞渗报错记录，后背发凉。透测目标站点的入漏登录接口，在用户名框输入一个单引号后，洞渗服务器直接吐出了完整的透测SQL查询语句——SELECT * FROM users WHERE username=''' AND password='...'。这不是入漏演习，是洞渗真实的渗透测试项目，对方是透测家做跨境电商的中型公司，防火墙开着，入漏WAF装着，洞渗但程序员显然把参数拼接当成了理所当然的透测事。

SQL注入的入漏本质，说白了就是洞渗攻击者把SQL代码“塞”进用户输入里，骗过数据库执行。透测别把它想得多高深，很多时候漏洞就藏在一句最简单的or 1=1里。我见过最蠢的案例，是某政务网站的后台，密码框直接拼进查询语句，连参数化查询都没做。测试时我输入' or '1'='1，回车，页面瞬间跳转到管理界面，那种感觉就像用万能钥匙捅开了一扇没上锁的门——一点成就感都没有，反而替他们着急。

但真实渗透测试里，情况往往更拧巴。你得先摸清后端用的是MySQL还是Oracle，是数字型注入还是字符型注入，甚至要判断是get请求还是post请求带参数。拿刚才那个跨境电商站点举例，我试了布尔盲注——通过页面返回的200和500状态码，逐字符猜解数据库名。用ascii(substr(database(),1,1))>100这类payload，配合二分法，硬是从几百个响应里拼出了shopdb。这个过程像做精细的拼图，急不得，稍有差池，IP就被WAF封了。

工具当然好用，sqlmap一把梭，自动跑出库名表名字段名，但工具跑出来的东西，有时候会骗你。有次sqlmap报告说目标存在时间盲注，我手动验证却发现延迟是网络波动造成的假象——那是个钓鱼网站，数据库根本没接到查询。所以高手做测试，一定先手工探测，确认注入点真实存在，再上工具扩大战果。手工注入讲究的是手感：输入1 and sleep(5)，看响应时间是不是真的卡了5秒；输入1 order by 10，看报错是否提示未知列。这些笨办法，比任何扫描器都可靠。

真正让我觉得这行有意思的，是绕过WAF的博弈。某次授权测试，目标网站装了云锁，我输入union select直接被拦，返回403。试了大小写混合、注释符/*!50000union*/、编码转换，通通没用。最后我盯着流量包发呆，突然想到——如果我把参数改成username=admin'/*&password=*/ or 1=1-- -呢？把注释符拆进两个参数里，WAF只检查单个参数的内容，结果绕过了。那一刻我差点拍桌子笑出来，这种对抗带来的兴奋感，比漏洞本身更让人上瘾。

但别忘了，渗透测试的底线是“授权”二字。我见过愣头青拿扫描器乱扫政府网站，结果被网警请去喝茶的。真要做测试，合同上白纸黑字写清楚测试范围、时间窗口、应急联系人，这是保护自己，也是尊重对方。哪怕漏洞再明显，也不能越雷池半步——技术是刀，握刀的手得稳。

那次跨境电商的渗透，最终在登录接口挖出三个注入点，其中一个能直接拖出全量用户表，包括明文存储的密码（是的，他们连哈希都没做）。写报告时我特意标注：修复方案不是加个过滤函数，而是全面改用预编译语句。但说实在的，就算我写了，对方CTO能不能听进去，又是另一回事。漏洞永远补不完，但每一次测试，至少能让那扇虚掩的门稍微关紧一点，这活儿就没白干。