必须同步完成代码层参数化改造，否则仅更新补丁或收紧数据库权限仍无法修复SQL注入漏洞；因补丁常遗漏非主路径拼接点，而最小权限无法阻止读取类攻击，唯有预处理语句+白名单校验+输入类型约束才能根治。
直接说结论：只更新补丁或只改数据库账号，都不足以修复SQL注入高危漏洞；必须同步完成代码层的参数化改造，否则攻击者仍能通过任意用户输入点触发漏洞。
为什么光靠更新补丁常常失效
很多CMS（如PHPCMS V9、DedeCMS V5.7.110、PHP168）的“官方补丁”本质是局部打补丁，比如只修了 /uploads/tags.php 里的 tag_alias 参数，但没动其他文件中同样拼接SQL的 $id、$keyword 或搜索框逻辑。一旦漏掉一个点，整站就等于没修。
常见现象包括：
- 升级后，日志里仍出现
SELECT * FROM `#@__tagindex` WHERE tag_alias = 'test' OR 1=1 -- '这类请求 - 安全扫描工具持续报出新路径下的
sql syntax error或mysql_fetch_array() expects parameter 1 to be resource - 攻击者利用未修复的旧模块（如答疑、评论、自定义表单）绕过补丁
数据库账号最小权限到底怎么设才有效
把账号从 root 改成只读，确实能限制部分破坏，但对绝大多数SQL注入场景作用有限——因为攻击者根本不需要写权限就能拖库。真正要卡住的，是执行能力本身。
实操建议：
- 禁止该账号使用
UNION SELECT、LOAD_FILE()、SLEEP()等高危函数（MySQL 8.0+ 可通过RESTRICTED SESSION角色控制） - 明确限定可访问的库名，不要用通配符
*；例如只授权GRANT SELECT ON mycms_db.* TO 'webuser'@'%'，而非GRANT ALL ON *.* - 禁用
FILE权限——这是防止写入Webshell的关键一环，SHOW GRANTS FOR 'webuser'@'%'必须确认不包含FILE
必须动手改代码：从拼接SQL到预处理语句
所有用户可控输入进入SQL前，都得走预处理。不是加个 addslashes() 或 safe_str() 就算完事——这些函数在多字节编码、宽字节注入、二次解码等场景下完全失效。
以 mysqli 为例，危险写法与修复对比：
/* 危险：直接拼接 */ $username = $_GET['username']; $sql = "SELECT * FROM users WHERE username = '$username'";
/* 安全：预处理绑定 */
$stmt = $mysqli->prepare("SELECT * FROM users WHERE username = ?");
$stmt->bind_param("s", $username);
$stmt->execute();关键注意点：
- 占位符只能用于**值**，不能用于表名、字段名、ORDER BY 子句——这些必须走白名单校验，比如
$order_field = in_array($_GET['sort'], ['title', 'created_time']) ? $_GET['sort'] : 'id'; - PDO 用户注意
PDO::ATTR_EMULATE_PREPARES必须设为false，否则 PHP 会模拟预处理，失去防护效果 - 老项目里大量
mysql_query()已废弃，必须迁移到mysqli或PDO，否则无法使用真正的预处理
最容易被忽略的验证盲区
开发者常以为“登录、注册、搜索”是重点，却漏掉这些地方：
- URL 路径参数：比如
/article-123.html中的123直接进SQL，未做is_numeric()校验 - HTTP 头字段：某些CMS会把
User-Agent或Referer写入日志表，而日志入库SQL也用了拼接 - JSON 接口：
$_POST是 JSON 字符串，json_decode()后直接取值拼SQL，没做类型断言 - 缓存键名：用用户输入生成
cache_key，再拿这个 key 去查数据库配置表，形成间接注入链
修复不是改完就结束的事——每个输入点都要回答一个问题：“这个变量有没有可能被攻击者控制？它最后会不会进SQL？” 漏掉任何一个，前面所有工作都白做。
