定期渗透测试不是“补漏动作”，而是让SQL注入这类隐蔽漏洞无法长期潜伏的必要节奏。
SQL注入漏洞具有强动态性，静态扫描根本覆盖不了
代码上线后，一次前端表单新增、一个API参数放开、甚至配置文件里加了个debug=true，都可能意外引入新的注入点。Nmap、Nessus这类工具扫不到业务逻辑层拼接SQL的地方；WAF日志里也看不到未触发的潜在路径。只有带上下文的手动探测+半自动验证，才能揪出SELECT * FROM users WHERE name = '$name'这种藏在PHP模板深处的裸拼写法。
- 新功能上线当天就可能带入注入点，但CI/CD流水线通常不跑深度安全用例
- 第三方SDK升级可能悄悄改掉ORM调用方式，把
queryBuilder->where()退化成字符串拼接 - 运维侧修改Nginx重写规则，把
/api/v1/user?id=1转成/user.php?id=1，绕过原有防护层
盲注类SQL注入必须靠时间维度验证，自动化工具容易误判
当目标系统关闭错误回显、过滤了union和select关键字、又没返回任何数据库字段时，' AND SLEEP(5)--是否真能延时，得靠真实请求+响应时间比对。Burp Suite的Intruder跑1000次请求，如果服务器本身网络抖动或负载高，SLEEP(5)实际耗时可能变成4.2s或5.8s——这时候只看阈值判断会漏掉真实漏洞。
- 手工验证要对比基线响应（如正常请求平均耗时120ms），再观察注入payload是否稳定高出400ms+
- 必须排除CDN缓存、WAF限速、数据库连接池排队等干扰因素
- 同一套payload在测试环境能延时，在生产环境可能被数据库连接超时直接截断
权限边界变化会让旧漏洞“复活”
某次数据库账号权限收紧后，information_schema查不了，你以为盲注失效了；结果半年后运维给应用账号加了FILE权限，攻击者立刻能用LOAD_FILE()读取/etc/passwd——而这个权限变更，不会触发任何代码扫描告警。
- 渗透测试要复测历史漏洞点，尤其关注数据库账号权限、MySQL插件启用状态、PostgreSQL的
dblink扩展等底层变动 - 内网横向移动场景下，一个原本只能读
users表的注入点，可能因DBA误配pg_shadow访问权限，突然变成提权入口 - 云环境里RDS实例的参数组更新、只读副本开启binlog，都可能改变注入利用链
真正卡住SQL注入的，从来不是某次测试报告里的“已修复”，而是每次发版前强制跑一遍sqlmap -u "https://api.example.com/user?id=1" --batch --level=3 --risk=2，再人工过一遍WHERE子句拼接逻辑——否则漏洞就在你改完代码的下一秒，静静躺在Git commit里等待上线。
