最现实的防护是加装Web服务器过滤器而非重写代码。通过UrlScan、mod_security、Nginx规则拦截高频SQL注入特征；部署SQL代理实现预编译重写；用日志分析识别盲注与二阶注入；统一接管错误页面防止信息泄露。
直接加装 Web 服务器过滤器，不改代码也能拦住大部分基础注入
老旧系统往往用 ASP/PHP 4.x/JSP + JDBC 直连数据库，源码缺失、框架陈旧、不敢动逻辑——这种情况下，最现实的防护不是重写，而是把拦截层“焊”在请求入口。IIS 的 UrlScan、Apache 的 mod_security（v2.9）、Nginx 的 ngx_http_geo_module + 自定义规则，都能在应用层之下完成初步清洗。
关键不是全防，而是卡住高频攻击特征：比如拒绝含 ' OR 1=1、UNION SELECT、SLEEP(、information_schema 的 GET/POST 参数值；对 URL 中连续出现的 %27（单引号编码）、%23（#号编码）做长度阈值限制（如单参数里超过 2 个 %27 就 403）。
- 不要依赖正则“完美匹配”，优先用字符串包含检测（快且兼容老规则引擎）
- IIS 下
UrlScan.ini中启用AllowHighBitChars=0可干掉大量十六进制编码绕过 - Apache 的
mod_security建议只加载 OWASP CRS 的REQUEST-932-APPLICATION-ATTACK-RCE.conf和REQUEST-942-APPLICATION-ATTACK-SQLI.conf两份规则，避免误杀老系统的特殊参数格式
对无法升级的数据库驱动，强制启用预编译语句代理层
有些系统用的是已停止维护的 JDBC 驱动（如 MySQL Connector/J 3.1.x），不支持 PreparedStatement 的安全绑定，但又不能换驱动——这时可部署轻量级 SQL 代理，如 mysql-proxy（Lua 脚本版）或开源的 sqlfirewall，在数据库连接池前截获原始 SQL，自动将 WHERE username = 'xxx' 类拼接语句重写为带占位符的预编译形式，并丢弃含 ; 的多语句请求。
这个方案不碰业务代码，只改连接地址（把应用里的 jdbc:mysql://db:3306 换成 jdbc:mysql://proxy:4040），但要注意两点：
- 代理必须开启严格模式：拒绝所有未显式声明参数类型的查询（如
SELECT * FROM users WHERE id = ?允许，SELECT * FROM users WHERE id = 1直接阻断） - 老系统若用
Statement.execute("DROP TABLE...")这类动态 DDL，代理需白名单放行特定账号（如仅允许schema_maintainer执行DROP） - MySQL 5.6+ 用户可直接启用
sql_mode=STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER，配合代理减少语法宽容度
绕过 WAF 的盲注和二阶注入，靠日志侧写比规则更有效
遗留系统常有搜索框、报表导出、用户资料编辑等接口，表面无回显、无报错，但实际存在布尔盲注或二阶注入风险。这类攻击不会触发传统 WAF 规则（因为 payload 看似合法），但会在数据库慢查询日志、应用访问日志中留下异常痕迹：比如同一 IP 在 1 分钟内发起 200+ 次响应时间波动在 4.8–5.2 秒的请求（疑似 SLEEP(5) 时间盲注），或某用户提交的昵称字段含 admin'-- 后，后续订单查询接口突然查出空结果（二阶触发点）。
低成本做法是写一个 50 行 Python 脚本，定时扫描 /var/log/mysql/slow.log 和应用 access.log，用固定模式匹配：
- 慢日志中提取
Query_time:> 4.5s 且含IF(、SLEEP(、BENCHMARK(的条目 - 访问日志中统计单 IP 的
ORDER BY、UNION、CONCAT(出现频次（即使被编码，%6f%72%64%65%72解码后仍是order） - 发现异常后自动封禁该 IP 并发邮件告警，不依赖实时拦截，但能快速定位真实攻击者
最易被忽略的点：错误页面没关，等于给攻击者发数据库说明书
很多老旧系统开发时开着 display_errors=On 或 show_sql_errors=true，导致 500 页面直接吐出 MySQL error: You have an error in your SQL syntax near 'xxx' ——这比任何文档都清楚地告诉攻击者当前字段数、表名结构、甚至数据库版本。
不用改代码，只要在 Web 服务器层统一接管错误响应：
- Apache：用
ErrorDocument 500 /generic-error.html，并确保该 HTML 不含任何动态内容 - IIS：在自定义错误页中禁用详细错误（
SendErrorsToBrowser=false），且关闭 ASP 的On Error Resume Next全局设置 - Nginx：配置
fastcgi_intercept_errors on，配合后端返回统一 500 页面
这件事成本趋近于零，但能直接废掉报错注入和大部分联合注入的探测效率。真正麻烦的从来不是怎么拦，而是老系统里那些没人敢动、但又明晃晃开着的调试后门。
