PHP 7.4升级8.0后旧SQL防御是否失效的检查方法

PHP 7.4升级到8.0后，旧版SQL注入防御代码还能用吗？安全排查指南

PHP 8.0正式发布已有相当长的时间，但大量项目的代码仓库中，依然遗留着许多针对PHP 7.4及更早版本设计的SQL注入防护逻辑。从7.4跃迁到8.0，这绝非一次简单的“功能增强”，而是一次彻底的“ABI断代”与“行为收紧”。许多在旧版本中“勉强可用但并不完善”的写法，到了8.0里要么直接报错中断，要么悄无声息地失去防护效果。

那么，完成PHP版本升级之后，过去依赖的那些防御手段还能继续信赖吗？以下四个关键检查点，是每个即将或已经完成PHP 8.0迁移的开发团队，都必须重新仔细审视的。

mysqli_real_escape_string()调用是否仍能正常生效

先给出结论：PHP 8.0并未物理移除 mysqli_real_escape_string()，但对其调用前置条件的要求变得更加严格。最核心的变化在于——如今它的第一个参数必须是一个有效的 mysqli 连接对象。如果数据库连接失败、尚未初始化就调用该函数，或者连接被提前执行了 mysqli_close()，脚本会直接抛出 Fatal error: Uncaught ValueError: mysqli_real_escape_string(): Argument #1 ($mysql) must be of type mysqli, null given。

在实际开发中，最容易踩坑的场景主要集中在以下三类：

• 老旧项目习惯将数据库连接句柄存放在全局变量或静态属性中，升级后如果连接意外断开，传入转义函数的就是一个 null。
• 直接使用 mysqli_connect() 却不做返回值校验，连接失败时得到的是 false，随后被当作对象传递给转义函数。
• 在CLI脚本或常驻进程（例如基于Swoole、ReactPHP构建的服务）中复用了长连接，连接超时断开后忘记重新建立。

如果项目中仍然大量依赖这个函数，以下几个安全兜底措施可以立即执行：

• 在每一个 mysqli_real_escape_string($conn, $str) 调用之前，添加一句 if (!$conn instanceof mysqli) { throw new RuntimeException('DB connection lost'); }。
• 不要想当然地认为“连接始终存在”。可以考虑封装一个安全的回退函数：直接返回 addslashes() 的处理结果，或者更理想的方案——直接转型，

  function safe_escape($conn, $str) {    return $conn instanceof mysqli ? mysqli_real_escape_string($conn, $str) : addslashes($str);}

  但说到底，最值得推荐的做法仍然是彻底放弃这种转义方式：改用 mysqli_prepare() 配合 mysqli_stmt_bind_param()，这才是真正意义上的“代码与数据分离”。

mysql_* 函数残留是否会引发致命运行错误

这一点最为明确也最为致命：PHP 8.0已经彻底移除了整个 mysql_* 函数家族，包括 mysql_real_escape_string()。只要脚本中还存在任何 mysql_* 调用，无论它位于哪个嵌套分支，只要被PHP解析器读取到，就会直接报错终止：Fatal error: Uncaught Error: Call to undefined function mysql_real_escape_string()。

最容易遗漏的高风险区域包括：

• 第三方插件或老旧CMS的模板文件（尤其是那些后缀为 .php 但内嵌大量HTML的混合文件），里面可能仍然藏着 mysql_real_escape_string()。
• 自定义的 db_helper.php 或 functions.php 中封装了一个所谓的“兼容层”，内部实际调用了 mysql_* 函数。
• 注释里写着 // mysql_real_escape_string() is deprecated 的代码——注释本身不会报错，但这说明项目对该函数依赖较深，需要顺着这条线索去追查实际调用点。

从实操角度来看，最高效的办法就是全局搜索：grep -r "mysql_real_escape_string|mysql_escape_string" . --include="*.php"。重点关注 ./plugins/、./includes/、./themes/*/template.php 这些非主框架目录。发现一处就修改一处，要么替换为 mysqli_real_escape_string()，要么直接改用预处理机制。

SQL注入防御逻辑是否因类型变更而被悄然破坏

这是一个极其隐蔽的问题。PHP 8.0 将许多旧版本中“隐式容错”的行为变成了硬性拦截，从而导致原有的防御链条断裂。最典型的情形就是：使用 intval() 或 (int) 强制转换用户输入后再拼接到SQL语句中。在旧版本中，这种做法虽然不够完善，但确实能够阻挡数字型注入攻击。然而在PHP 8.0里，如果原始输入是 null 或布尔值，强制类型转换会直接抛出 TypeError，连SQL拼接那一步都无法执行。

例如下面这段曾经被认为“安全”的代码：

$id = $_GET['id'] ?? null;
$sql = "SELECT * FROM users WHERE id = " . (int)$id;

在PHP 7.4中能够正常运行，但在8.0中会直接崩溃，因为 (int) null 触发了 TypeError。

正确的处理方式是，所有用于SQL拼接的变量，在执行任何操作之前，先进行类型归一化处理：$id = filter_input(INPUT_GET, 'id', FILTER_VALIDATE_INT) ?: 0;。或者更严谨一些，使用 filter_var() 显式声明处理意图。不要再依赖 (int) 或 intval() 去处理那些可能为 null 的输入值了。

与此同时，需要检查所有 WHERE id = ? 类型的查询，确保在占位符绑定之前，变量已经通过了有效性判断，而不是依靠类型转换来“碰运气”。

PDO::quote() 是否因扩展未重新编译而静默失效

最后这个检查点，可能很多团队都没有留意到。PDO::quote() 函数本身并未被移除，但其底层完全依赖于PDO MySQL驱动。PHP 8.0 的ABI与PHP 7.4完全不兼容。如果你是从旧环境直接把 pdo_mysql.so 复制过来的，或者像宝塔这类面板没有帮你自动重新编译扩展，那么这个方法可能正在悄无声息地失效——返回空字符串、false，甚至不报任何错误就直接放行了恶意字符。

验证方法也很直接：

• 执行 php --ri pdo_mysql，确认输出中包含 PDO Driver for MySQL => enabled，并且版本号 ≥ 8.0。
• 手动进行测试：

  $pdo = new PDO("mysql:host=127.0.0.1;dbname=test", "root", "");
  var_dump($pdo->quote("'; DROP TABLE users; --")); // 应返回带引号的转义字符串，不是空或 false

• 直接检查 /www/server/php/80/lib/php/extensions/no-debug-non-zts-20200930/pdo_mysql.so 文件是否存在（路径中的 20200930 是PHP 8.0的ABI标识）。

需要时刻牢记的是：扩展文件存在，并不等于功能一定可用。哪怕 php -m 输出了 pdo_mysql，只要ABI不匹配，quote() 返回的结果就可能完全不正常，而且没有任何明确的报错信息。这或许是PHP 8.0升级过程中最安静的“后门”隐患。