怎样修复遗留系统中的SQL注入高危漏洞？

SQL注入在遗留系统中必须用参数化查询修复，禁用拼接式SQL；数字参数强制转整型，字符参数必须用prepare+bind_param；ORDER BY和LIMIT需白名单校验；WAF仅应急，修复后须手工验证绕过。

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

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