如何为遗留老旧系统低成本加装防护拦截SQL注入？-SQL-PHP中文网

最现实的防护是加装Web服务器过滤器而非重写代码。通过UrlScan、mod_security、Nginx规则拦截高频SQL注入特征；部署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'-- 后，后续订单查询接口突然查出空结果（二阶触发点）。

Presale One-pass Orchestrator

一款AI工具，主要用于运行或监督单遍 Codex 实现，包含预检门控、分步计划执行及严格的 QA 缺陷闭环。适用于执行已批准的售前...，适合需要提升相关任务效率的用户。

下载

低成本做法是写一个 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 页面

这件事成本趋近于零，但能直接废掉报错注入和大部分联合注入的探测效率。真正麻烦的从来不是怎么拦，而是老系统里那些没人敢动、但又明晃晃开着的调试后门。