前言先把一个容易误导人的前提说清楚防止 SQL 注入SQL Injection和 PHP 的版本号没有关系。标题里的「PHP 8.4」只是运行环境真正管用的是 PDO 的预处理Prepared Statement机制这套东西从 PHP 5.1 就已经有了PHP 7.0 移除了老掉牙的mysql_*系列函数此后几乎所有项目都走 PDO 或 mysqli而 PHP 8.4 在这件事上带来的只是几处语法层面的小便利例如array_find()。所以本文不会把 8.4 的新特性硬套到防注入上而是按 PHP 8.4 的环境讲真正有效的做法。典型症状接口上线后某天数据库里多了一批莫名其妙的账号或者某个查询接口被人加上?id1 OR 11就能拉到全表。这类问题的根因永远只有一个——把「数据」拼接进了「SQL 语句」让数据库把用户输入当成了代码执行。PDO 的预处理之所以有效是因为它把 SQL 语句结构先发给数据库编译一次参数值走的是独立的传输通道永远不参与语法解析。本文覆盖四件事预处理为什么能防住注入、ORDER BY/LIMIT/IN这几个预处理「管不到」的死角怎么处理、错误处理与字符集相关的连带风险以及一个可以直接跑起来验证的完整示例。一、注入的本质数据变成了代码看一段拼接写法?php // 危险字符串拼接 $name $_GET[name]; $sql SELECT id, name FROM users WHERE name $name; $rows $pdo-query($sql)-fetchAll();当name的取值是 OR 11时最终发给数据库的语句变成SELECT id, name FROM users WHERE name OR 11条件恒真全表返回。攻击者还能继续用UNION SELECT把information_schema里的表名拖出来或者用;加一条DROP TABLE。根因不是「引号没过滤干净」而是用户输入被拼进了语法结构里。预处理的解法?php // PHP 8.0 $stmt $pdo-prepare(SELECT id, name FROM users WHERE name :name); $stmt-execute([name $_GET[name]]); $rows $stmt-fetchAll();:name是一个占位符placeholder它只会被当作「一个值」来传输。哪怕值里含引号、分号、注释符也不会改变语句结构。做法用户输入是否进入语法解析结论字符串拼接会必然可注入addslashes()/PDO::quote()后拼接会靠转义博弈字符集不推荐特定字符集下仍可注入PDO::prepare() 绑定参数不会正确做法存储过程内动态拼 SQL会一样会注入别迷信存储过程二、四个预处理管不到的死角占位符只能替代值不能替代标识符表名、列名和部分语法结构。下面这四处必须换思路。死角一ORDER BY的列名。绑定参数会被当成字符串常量排序直接失效或报错。正确做法是白名单映射?php // PHP 8.0 $allow [created_at created_at, name name, id id]; $key $allow[$_GET[sort] ?? id] ?? id; $stmt $pdo-prepare(SELECT id, name FROM users ORDER BY {$key} DESC LIMIT 20);注意进prepare()的字符串必须来自代码里写死的数组不能是用户输入的拼接结果。死角二LIMIT/OFFSET。绑定时要显式指定整型?php // PHP 8.0 $stmt $pdo-prepare(SELECT id FROM users LIMIT :limit OFFSET :offset); $stmt-bindValue(:limit, (int) $limit, PDO::PARAM_INT); $stmt-bindValue(:offset, (int) $offset, PDO::PARAM_INT); $stmt-execute();如果开启了模拟预处理PDO::ATTR_EMULATE_PREPARES trueMySQL 下默认就是开启的不指定PDO::PARAM_INT时参数会被当字符串加引号LIMIT 20就会语法报错这也是很多人「换了个写法就报错」的原因。死角三IN (...)列表。IN (?)只代表一个值。要按数组长度生成占位符?php // PHP 8.0 $ids array_values(array_unique(array_map(intval, $ids))); $ph implode(,, array_fill(0, count($ids), ?)); $stmt $pdo-prepare(SELECT id, name FROM users WHERE id IN ($ph)); $stmt-execute($ids);当然如果数组本身就是整数用array_map(intval, ...)之后再拼接也是安全的因为已不再是字符串但生成占位符更不容易在后续维护中被改坏。死角四LIKE通配符。%和_是语法的一部分需要转义后再绑定?php // PHP 8.0 $kw str_replace([\\, %, _], [\\\\, \\%, \\_], $keyword); $stmt $pdo-prepare(SELECT id FROM users WHERE name LIKE :kw ESCAPE \\\\); $stmt-execute([kw % . $kw . %]);PHP 8.4 里可以用array_find()帮白名单查表写得更清晰例如从一张合法的排序字段表里找匹配项?php // PHP 8.4 $orderable [id, name, created_at]; $requested $_GET[sort] ?? id; // array_find 返回第一个满足条件的元素找不到返回 null $column array_find($orderable, static fn (string $c): bool $c $requested) ?? id;这里只用了 PHP 8.4 的语法便利防注入本身靠的仍然是「白名单 写死」。三、容易被忽略的连带风险字符集。连接建立后要立刻把字符集设成utf8mb4并且不要用它来「防注入」——真正的价值是避免某些宽字节字符集如 GBK在转义时被绕过。推荐直接在 DSN 里指定; 只是示意实际写在 PHP 里 mysql:host127.0.0.1;dbnameapp;charsetutf8mb4错误回显。生产环境关掉display_errorsPDO 用ERRMODE_EXCEPTION把错误变成异常异常信息只进日志不要回给接口调用方。把 SQL 报错原样返回等于免费送给攻击者一张表结构图。二次注入Second-Order Injection。数据入库时用了预处理取出来拼进另一条 SQL 时又变成拼接这叫二次注入。凡是「数据库里取出来的值再参与拼 SQL」的地方都要重新走一遍预处理。四、完整可运行示例下面的脚本用 SQLite 内存库只要pdo_sqlite扩展可用就能直接运行PHP 8.4 环境。它对比了拼接写法和绑定写法的结果差异并演示白名单排序与IN列表占位符。?php declare(strict_types1); // PHP 8.4PDO 部分 PHP 8.0 通用 $pdo new PDO(sqlite::memory:, null, null, [ PDO::ATTR_ERRMODE PDO::ERRMODE_EXCEPTION, PDO::ATTR_DEFAULT_FETCH_MODE PDO::FETCH_ASSOC, ]); $pdo-exec(CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT, created_at TEXT)); $ins $pdo-prepare(INSERT INTO users (name, created_at) VALUES (?, ?)); foreach ([alice, bob, carol] as $i $n) { $ins-execute([$n, sprintf(2026-01-%02d, $i 1)]); } $attack OR 11; // 1) 危险写法拼接。这里只为演示真实项目绝不要这么写 $sql SELECT id, name FROM users WHERE name $attack; $bad $pdo-query($sql)-fetchAll(); echo 拼接写法返回行数: , count($bad), PHP_EOL; // 2) 正确写法预处理 绑定 $stmt $pdo-prepare(SELECT id, name FROM users WHERE name :name); $stmt-execute([name $attack]); $good $stmt-fetchAll(); echo 绑定写法返回行数: , count($good), PHP_EOL; // 3) ORDER BY 白名单 $orderable [id, name, created_at]; $requested $_GET[sort] ?? name; $column array_find($orderable, static fn (string $c): bool $c $requested) ?? id; $stmt $pdo-prepare(SELECT id, name FROM users ORDER BY {$column} ASC); $stmt-execute(); echo 排序字段: , $column, - , implode(,, array_column($stmt-fetchAll(), name)), PHP_EOL; // 4) IN 列表占位符 $ids [1, 2, abc, 2]; $ids array_values(array_unique(array_map(intval, $ids))); // 顺便去重、过滤非法值 $ph implode(,, array_fill(0, count($ids), ?)); $stmt $pdo-prepare(SELECT id, name FROM users WHERE id IN ($ph) ORDER BY id); $stmt-execute($ids); echo IN 查询命中: , implode(,, array_column($stmt-fetchAll(), name)), PHP_EOL; // 5) LIMIT 绑定SQLite 下同样需要显式整型 $stmt $pdo-prepare(SELECT id FROM users ORDER BY id LIMIT :limit OFFSET :offset); $stmt-bindValue(:limit, 2, PDO::PARAM_INT); $stmt-bindValue(:offset, 1, PDO::PARAM_INT); $stmt-execute(); echo LIMIT 分页: , implode(,, array_column($stmt-fetchAll(), id)), PHP_EOL;预期输出拼接写法返回行数: 3 绑定写法返回行数: 0 排序字段: name - alice,bob,carol IN 查询命中: alice,bob LIMIT 分页: 2,3第一行 3 就是被注入的后果恶意输入让条件恒真全表被拖走第二行的 0 才是正确结果。常见坑点坑 1以为绑定了参数就万事大吉然后把表名也拼进去。❌SELECT * FROM {$prefix}_users WHERE id :id$prefix来自配置或请求参数时同样可注入。 ✅ 表名走白名单常量数组绝不来自外部输入。坑 2IN (?)里塞逗号分隔的字符串。❌execute([implode(,, $ids)])会被当成一个字符串值永远只匹配到一行或零行。 ✅ 按数组长度生成?,?,?占位符或先array_map(intval, ...)再拼接。坑 3用PDO::quote()或addslashes()代替预处理。❌ 两者都是「转义博弈」在连接字符集与转义函数理解不一致时能被绕过addslashes()从来不是为 SQL 设计的。 ✅ 一律使用绑定参数quote()只在无法使用占位符的极少数场景兜底。坑 4开了模拟预处理却以为安全。❌ MySQL 下PDO::ATTR_EMULATE_PREPARES默认为true此时参数由 PDO 做转义后拼进 SQL虽然 PDO 的转义实现相对可靠但字符集配置错误时会露出宽字节注入的口子。 ✅ 连接时设置PDO::ATTR_EMULATE_PREPARES false使用真正的服务端预处理并显式指定charsetutf8mb4。坑 5LIMIT绑定不指定PDO::PARAM_INT。❌ 模拟预处理下LIMIT 20会直接语法错误报错信息看起来跟注入毫无关系非常费时间。 ✅ 用bindValue(:limit, (int) $n, PDO::PARAM_INT)。坑 6把 SQL 报错原样返给接口调用方。❌ 报错里往往带着完整的 SQL、表名和列名等于把数据库结构送给攻击者。 ✅ 生产环境display_errorsOffPDO 设ERRMODE_EXCEPTION异常统一记录到日志后返回通用错误码。坑 7只防第一次写入忽略二次注入。❌ 评论内容用预处理存进库后台导出时又... WHERE content LIKE %{$row[content]}%攻击者早就把 payload 存进去了。 ✅ 凡是数据库取出的值再次参与 SQL 拼接的地方必须重新用绑定参数。坑 8把「前端做了校验」当成防线。❌ 只在 JavaScript 里限制输入格式攻击者用 curl 直接打接口就绕过了。 ✅ 所有校验都在服务端做前端校验只是体验优化。总结场景正确做法普通条件值WHERE/SET/VALUESprepare() 绑定参数表名、列名、排序字段代码内写死的白名单数组映射LIMIT/OFFSET绑定并显式PDO::PARAM_INTIN列表按数组长度生成占位符LIKE关键词转义%_\后绑定并声明ESCAPE连接字符集DSN 里写charsetutf8mb4不要依赖转义错误信息只进日志不回显 SQL二次使用数据重新走预处理SQL 注入的防法十几年没变过一句话就能说完SQL 语句的结构必须由代码决定用户数据只能通过参数通道进入。PHP 8.4 也好8.5 也好都改变不了这条规则。真正让项目出事的从来不是语言版本而是那几个「参数替代不了语法结构」的死角——ORDER BY、LIMIT、IN、表名以及「从库里取出来又拼一遍」的二次注入。
