PHP项目中自定义查询类如何防SQL注入?

作者:袖梨 2026-07-09
自定义SQL查询类必须强制走预处理绑定路径,禁止字符串拼接;所有用户输入参数须通过占位符传入,动态表名/字段名需白名单校验,IN语句要手动展开占位符,输入验证不能替代预处理。

直接用字符串拼接构建 SQL 的自定义查询类,哪怕加了 addslashes()mysqli_real_escape_string(),也挡不住 SQL 注入——这不是加固问题,是架构缺陷。

自定义查询类必须强制走预处理绑定路径

很多团队写所谓“通用查询类”,底层仍用 mysql_query()mysqli_query() 拼接字符串,再套一层方法名包装,本质没变。真正安全的自定义类,所有执行入口(如 select()update())内部必须调用 prepare() + execute(),且禁止开放原始 SQL 拼接接口。

  • 类构造时就要持有已配置好的 PDOMySQLi 实例,且该实例已禁用模拟预处理:PDO::ATTR_EMULATE_PREPARES => false
  • 所有接受用户输入的参数(如 where 条件、limit 值、order 字段)必须通过占位符传入,不能在 SQL 字符串里插值
  • 如果类提供 raw()expr()setSql() 这类方法,必须默认禁用,或仅限白名单内固定语句(如 "NOW()"

动态表名/字段名必须白名单硬校验

预处理占位符 ?:name 只能用于数据值,不能用于标识符(表名、列名、ORDER BYGROUP BY)。自定义类若支持动态字段,就得提前约定允许范围,运行时只做匹配,不作任何转义。

  • 例如排序字段:先定义 $allowedSortFields = ['id', 'created_at', 'status'],再用 in_array($_GET['sort'], $allowedSortFields) ? $_GET['sort'] : 'id'
  • 表名映射更稳妥:$tableMap = ['user' => 'users', 'order' => 'orders']; $realTable = $tableMap[$_GET['type']] ?? 'users';
  • 绝对不要用 filter_var($input, FILTER_SANITIZE_STRING) 处理字段名——它删 HTML 标签,不防 SQL 注入

IN 语句和批量参数要手动展开占位符

预处理不支持数组直接绑定到 IN (?),自定义类若封装了 whereIn(),必须动态生成对应数量的 ?,再把数组值平铺进参数列表。

立即学习“PHP免费学习笔记(深入)”;

  • 错误写法:"WHERE id IN (?)", [$ids] —— 这只会把整个数组转成字符串,变成 IN ('Array')
  • 正确做法:先用 str_repeat('?,', count($ids) - 1) . '?' 构造占位符串,再用 array_values($ids) 提取纯数值参数
  • 注意类型一致性:整数数组就用 bind_param('i', ...),字符串数组用 's',混合类型需拆开处理

别信“输入验证能替代预处理”

有人觉得“我用了 filter_var($id, FILTER_VALIDATE_INT),拼接就安全了”,这是错觉。整数校验防不了逻辑绕过(比如传 -1 OR 1=1),也防不了字符集攻击(如宽字节截断),更防不了业务层误用(比如把校验过的 ID 当用户名拼进另一个查询)。

  • 输入验证是必要补充,不是替代方案:数字转 (int)、邮箱用 FILTER_VALIDATE_EMAIL、长度超限直接 return false
  • 但只要代码里还存在 "SELECT * FROM {$table} WHERE id = " . $id 这种模式,验证就形同虚设
  • 最危险的是“半预处理”:部分参数绑定,部分拼接——攻击者会专攻未绑定的那部分

真正难的不是写对一个 prepare(),而是让整个查询类的所有分支路径都走同一套绑定机制,且不允许任何例外。一旦放开一个口子(比如为“兼容旧逻辑”加个 unsafeRawQuery()),整套防护就归零。

相关文章

精彩推荐