MySQL项目注入漏洞修复方法与安全防护指南

addslashes() 并不能修复 SQL 注入漏洞，因为它只会转义少量特定字符，既不了解 SQL 语义，也无法正确处理不同字符集场景。面对数字型参数注入、宽字节绕过、二次注入等常见攻击方式时，它几乎没有防护能力；真正可靠的做法只有使用 PDO 或 MySQLi 预处理并绑定参数，同时关闭模拟预处理。

修复 MySQL 项目 SQL 注入问题，唯一可信的方法是使用 PDO::prepare() 或 mysqli_prepare() 进行预处理。其他所谓防注入手段，例如 addslashes()、正则过滤、关键词黑名单等，在真实的攻击环境中通常都不可靠，难以从根本上解决安全风险。

为什么 addslashes() 不能防注入

addslashes() 仅对单引号、双引号、反斜杠以及 NULL 字符做简单转义，但对于数字型 SQL 注入（例如 id=1 OR 1=1）完全不起作用。更关键的是，它根本不理解数据库连接字符集——如果 MySQL 连接层使用 GBK，而 PHP 端又没有显式调用 mysqli_set_charset()，那么像 %A1%27 这样的宽字节数据就可能直接绕过转义。另外，当数据库中的数据被再次读取并拼接进新的 SQL 语句时，也就是典型的二次注入场景，addslashes() 更是彻底失效。

• addslashes() 无法区分不同上下文：字符串、数字、表名虽然都可能进入 SQL，但数据库对它们的解析规则并不相同，使用同一套转义逻辑本身就不安全
• 它不能阻止 WHERE id = ? 这类位置传入恶意字符串 "1 OR 1=1" —— mysqli 可能发生隐式类型转换，而 PDO 在 PDO::ATTR_EMULATE_PREPARES = true（默认开启）时也存在风险
• 虽然现代 MySQL 大多默认使用 utf8mb4，但如果连接字符集没有明确设置，依旧可能出现宽字节注入漏洞

PDO::prepare() 和 mysqli_prepare() 怎么选

实际开发中更推荐使用 PDO：它的抽象层更稳定，错误处理方式更统一（例如 PDO::ERRMODE_EXCEPTION），同时支持命名占位符（:username）和问号占位符（?），因此在维护旧项目或迁移代码时会更加方便。如果现有 MySQL 项目已经深度依赖 mysqli，那么也可以继续使用，但必须确保启用真正的预处理流程，并在建立连接后第一时间调用 mysqli_set_charset($conn, 'utf8mb4')。

• mysqli 仅支持问号占位符，参数绑定需要通过 bind_param() 完成，若类型标记（s/i/d）写错，可能导致静默失败，例如本应传 i 却误写成 s
• 无论是 PDO 还是 mysqli，都要求在执行 prepare 之前完成数据库连接初始化，而且预处理语句对象不能跨连接复用
• PDO 默认启用模拟预处理（PDO::ATTR_EMULATE_PREPARES = true），必须显式设置为 false，才能使用真正的服务端预编译，从源头降低 SQL 注入风险

参数绑定前必须做输入校验

需要注意的是，预处理可以防止 SQL 注入，但并不能替代输入验证，也不能避免业务逻辑层面的错误。例如用户提交 id=-999 或 id=99999999999999999999，仍然可能引发越权访问、整数溢出或者隐式类型转换等问题。

• 数字参数建议先使用 filter_var($x, FILTER_VALIDATE_INT) 或 intval() 做基础清洗和校验，再传给 bind_param() 或 execute()
• 枚举类参数（如 status=active）必须采用白名单校验，例如 in_array($status, ['active', 'inactive'], true)，不能单纯依赖预处理
• 表名、字段名这类标识符不能使用占位符绑定，只能通过硬编码或严格白名单映射来处理，例如 $table_map = ['user' => 'users', 'log' => 'logs']

最容易被忽略的执行环节

很多项目已经写了 prepare，却依然存在 SQL 注入隐患，问题通常出现在执行链路的细节上：例如没有检查 execute() 的返回结果，导致绑定失败却未被发现；或者在日志、调试分支中仍然使用 mysqli_query() 直接执行拼接 SQL；再比如事务处理不完整，出现异常时无法正确回滚。

• mysqli_stmt::execute() 和 PDOStatement::execute() 都会返回布尔值，必须显式判断，否则即使参数绑定失败，也可能表现为查询无结果却没有错误提示
• 不要混合使用预处理与字符串拼接：如果一个查询只对部分参数做了 prepare，其余部分仍然拼接文本，整个 SQL 依旧可能被绕过
• 所有数据库访问最好统一封装在一个入口中，明确禁止直接调用 mysqli_query() 或 PDO::query() 执行裸 SQL

修复 SQL 注入漏洞的关键，并不只是“会不会写预处理”，而是“能不能保证每一条 SQL 都通过预处理执行”。只要漏掉任何一处字符串拼接，整个防御体系就可能失效。真正危险的不是不会写，而是看似已经做了防护，实际上却没有完整覆盖。