凌晨两点，注战我盯着Burp Suite里那个红色的入漏告警标记，手里的洞扫咖啡差点洒在键盘上——一个看似普通的搜索框，后端竟然直接拼接了SQL语句。描实参数`id=1`被替换成`1 AND SLEEP(5)`，注战响应时间立刻拉长到5.3秒。入漏这不是洞扫测试环境，是描实客户的生产库，里面有几十万条用户记录。注战

那次之后我养成了个习惯：看到任何输入框，入漏先不急着填内容，洞扫而是描实用单引号`'`去探路。一个报错提示、注战一个奇怪的入漏跳转，都可能暴露拼接点。洞扫说实话，手动探测的效率太低，但脚本扫出来的结果又经常让人哭笑不得——有些工具把加密参数也当成注入点，误报率能到百分之七八十。

真正动手扫的时候，我一般分三步走。第一步是抓包，把请求原样存下来，用sqlmap跑基础检测。`sqlmap -r request.txt --batch --level 3`，这命令我闭着眼都能敲出来。但别指望它一次就出结果，很多站点的防护规则会拦截明显特征，比如`UNION SELECT`这种关键字。这时候得换个思路，用`--tamper=space2comment`把空格替换成注释符，或者用`--random-agent`换个浏览器标识，绕开WAF的基础过滤。

第二步是手工验证。工具报“疑似注入”不代表真能利用，得自己构造payload确认。我记得有个案例特别典型：某后台登录接口，参数`username`存在注入，但sqlmap跑出来的数据全是乱码——因为数据库编码是GBK，而工具默认用UTF-8解析。换成`--charset=GBK`之后，数据立刻正常了。这种坑，光靠自动化工具根本发现不了，得对目标系统的技术栈有基本判断。

第三步才是真正的“实战”——拿到数据后的处理。有一次扫出个DBA权限的注入点，能直接读文件。我试着读取`/etc/passwd`，成功了；接着尝试写webshell，结果被系统目录权限挡住了。但那次经历让我明白：扫描只是起点，后续的利用和修复建议才是客户真正付钱的原因。报告里不能只写“存在SQL注入”，得说清楚影响范围、可获取的数据类型、修复方案——比如改用参数化查询、对输入做白名单校验，还有最小化数据库账号权限。

说个反直觉的事儿：很多高危漏洞其实藏在老旧的内部系统里，而不是对外官网。有次我扫一个2012年上线的OA系统，用的是ASP+Access数据库，连sqlmap都懒得识别这种组合。但就是这种“过时”技术栈，往往连基础防护都没有。我手工试了试`admin' or '1'='1`，竟然直接进了后台——密码都不需要猜。这提醒我，扫描工具不是万能的，对老系统的判断更多靠经验，而不是依赖版本库更新。

写到这里，想起上周帮朋友排查一个电商站。他们的安全团队用商业扫描器测过，报告显示“无风险”。但我在商品详情页的`sort`参数里发现了个时间盲注——每请求一次，数据库就延迟2秒。这种盲注很难被常规扫描器发现，因为响应内容完全正常，只是时间上有微弱差异。我手工构造了`ORDER BY`子句的payload，才把注入点逼出来。所以说，工具是死的，思路是活的。真正有效的扫描，永远是“自动化初筛+人工深挖”的组合拳，缺一不可。

最后提一句，别把扫描结果当成安全证书。今天修完的漏洞，明天换个参数可能又冒出来。定期扫、随手测，把它变成习惯，比依赖任何“终极工具”都靠谱。