自动化SQL注入压测是验证防护链路是否在真实流量路径全程生效的过程，而非简单判断有无漏洞；其失效主因包括字符集未对齐、动态语句分支未覆盖、Nginx解码层错位、二阶注入场景缺失校验等。
自动化SQL注入压测不是“有没有漏洞”的判断题，而是“你的防护链路是否在真实流量路径上全程生效”的验证过程。单纯加了 mysqli_real_escape_string 或用了 PreparedStatement，但没对齐字符集、没覆盖动态语句分支、没处理 Nginx 解码层，压测一跑就漏。
为什么基础过滤在压测中会失效
很多团队看到代码里写了转义或预编译，就默认“防住了”。但自动化压测工具（如 sqlmap 的 --level=5 --risk=3）会刻意绕过表层防护：
-
SET NAMES utf8和实际建表字符集为utf8mb4不一致时，%C0%A7宽字节可截断绕过addslashes - Nginx 配置了
underscores_in_headers on，又把User-Agent里的'自动解码成单引号，而 PHP 层根本没收到原始编码——过滤逻辑完全错位 - ORM 中
ORDER BY ?这类动态字段无法用参数化，但开发者忘了加白名单校验，压测时用id ASC, (SELECT SLEEP(5))直接触发时间盲注
行为一致性监控比拦截率更重要
有效防护的信号不是“所有恶意请求都返回 403”，而是响应行为稳定、无信息泄露、无延迟突变：
- 同一 payload（如
' OR SLEEP(3)--）在WHERE id=?和ORDER BY ?两个上下文中，响应时间差应 - 检查 MySQL 的
slow_query_log，重点抓含SLEEP、BENCHMARK、WAITFOR的慢查询条目数突增 - 对比正常请求与恶意请求的
Content-Length：若某类 payload 触发了数据库错误并回显（如mysql_fetch_array(): supplied argument is not a valid MySQL result resource），说明错误页面未关闭调试模式
限流策略必须绑定攻击指纹，不能只看 QPS
按 IP 限速容易被代理池绕过；按 URL 限速又会误伤正常搜索。真正有效的限流要基于攻击行为建模：
- 识别高频出现的注入特征：连续 3 次请求中
Cookie或body含%27、%E2%80%99、%C0%A7、/*+*/、UNION SELECT等变体 - 对命中指纹的 session ID 或 JWT 主体做 10 秒内最多 2 次 SQL 相关接口调用，超限返回 429 并记录
X-SQLi-Fingerprint响应头 - 避免全量扫表式探测：压测工具若在 1 秒内对同一接口发起 >20 个不同 payload，直接熔断该连接池，防止打满数据库连接
最常被忽略的点是字符集对齐和多阶段注入场景——比如用户名注册时存入 admin'--，后续修改密码接口再拼接进 SQL，这种二阶注入连 WAF 都难捕获，必须靠应用层输入白名单 + 执行前二次校验。
