首页 > 数据库 >如何修复遗留系统SQL注入高危漏洞？

如何修复遗留系统SQL注入高危漏洞？

来源：互联网 2026-07-12 08:37:12

针对遗留系统SQL注入漏洞，参数化查询是唯一可靠解法。数字型参数需强制类型转换，字符型需改用预处理语句。ORDERBY和LIMIT无法参数化，需依赖白名单和数值范围限制。WAF规则仅应急，不能替代代码修复，需重点排查隐式拼接点。修复后需用手工payload和日志验证效果。

SQL注入在遗留系统里怎么修？不是“能不能”，而是“怎么修才不崩”

说实话，SQL注入这个问题在遗留系统里，早就不是“能不能修”的层面了——真正头疼的是“怎么修才不崩业务、不漏死角”。参数化查询是唯一可靠的解法，其他手段要么是临时止血，要么就是掩耳盗铃。下面直接上干货。

最危险的：直接改 `mysql_query()` 和 `mysqli_query()` 的拼接逻辑

很多老PHP系统还在用 mysql_query("SELECT * FROM user WHERE id = " . $_GET['id']) 这种写法。别想着加个 addslashes() 或 mysql_real_escape_string() 就能高枕无忧——GBK宽字节、多层编码、反斜杠后跟特殊字节，随手就能绕过。更糟的是，mysql_* 函数早就被PHP弃用了，运行时警告都可能引发兼容性问题。

长期稳定更新的攒劲资源： >>>点此立即查看<<<

实操建议：

逐个定位所有 mysql_query()、mysqli_query()（未用预处理）、pg_query()（未用 pg_query_params()）的调用点，优先从登录、搜索、详情页这些高频入口开始排查。
数字型参数（比如 id=123），先强制转成 (int) 或 filter_var($id, FILTER_VALIDATE_INT)，再拼进SQL——这能挡住大部分基础注入，但仅限纯数字场景。
字符型参数（比如 name=xxx），必须改写成 mysqli_prepare() + bind_param()，不能只换函数名，要拆出SQL模板和变量分离。

`ORDER BY` 和 `LIMIT` 子句没法参数化，只能靠白名单

这是遗留系统里最常被忽略的盲区。举个例子：$sql = "SELECT * FROM news ORDER BY " . $_GET['sort'] . " DESC LIMIT " . $_GET['limit'] ——ORDER BY 后面不能用占位符，数据库会直接报错；LIMIT 的值也不能简单用绑定（MySQL允许，但PostgreSQL不行，部分旧驱动也不支持）。

实操建议：

sort 参数只允许从固定数组里取值：$allowed_sorts = ['title', 'created_at', 'view_count']; if (!in_array($_GET['sort'], $allowed_sorts)) die('invalid sort');。
limit 参数用 min(max((int)$_GET['limit'], 10), 100) 限定范围，避免传入负数或极值导致全表扫描。
不要用正则去“过滤 ;、--、#”，攻击者可以用内联注释 /**/ 或换行绕过，白名单才是最彻底的方案。

WAF规则只能应急，别指望它替代代码修复

上线一条 SecRule ARGS "@rx (union\s+select|sleep(|'or'\d+=')" 的ModSecurity规则，确实能挡住sqlmap扫出来的90%流量。但真实攻击者早就不走这些明面路径了：十六进制编码、JSON body里的payload、sort=IF(1=1,username,1) 这种布尔盲注，WAF根本不会匹配。

实操建议：

把WAF日志里“被放行但含 %27、%3B、%20OR%20”的请求全部导出，按参数名分组——出现频次最高的参数，就是代码里最该优先修的拼接点。
禁用WAF的“严格模式”，否则用户昵称 O'Connor、订单号 ORD-2024-AND-001 会被误杀，引发客诉。
确认WAF开启了 SecRequestBodyAccess On 并配置了JSON解析器，否则 {"q":"admin' OR 1=1--"} 这类POST请求永远进不到检测逻辑里。

修复后必须验证是否真生效，不是看页面还能打开就完事

改完代码跑一遍单元测试，页面没报错 ≠ 漏洞已修复。攻击者不需要看到报错，只要能通过响应时间差（sleep(5)）、布尔条件（id=1 AND 1=1 vs id=1 AND 1=2）或报错信息里的字段名，就能确认注入点是否存活。

实操建议：

用手工payload验证：访问 /userid=1 AND 1=1 和 /userid=1 AND 1=2，对比HTTP状态码、响应体长度、响应时间。
检查数据库慢查询日志，确认是否还有带用户输入的原始字符串出现在 WHERE 或 ORDER BY 中。
对每个修复点，额外测一次编码绕过：/userid=1%2527%20OR%201%3D1（双重URL编码），确保过滤或绑定逻辑在解码后仍有效。

真正难的不是写对那几行 prepare() 和 bind_param()，而是找出所有隐式拼接点——比如日志记录函数里悄悄把 $_SERVER['REQUEST_URI'] 写进了SQL，或者某个ORM封装层底层还是用字符串拼接生成SQL。这些地方，不翻源码、不抓包、不查日志，永远看不见。

侠游戏发布此文仅为了传递信息，不代表侠游戏网站认同其观点或证实其描述