PHP自定义查询类防SQL注入的实用方法

直接通过字符串拼接构建 SQL 的自定义查询类，即便使用了 addslashes() 或 mysqli_real_escape_string() 进行过滤，依然无法抵御 SQL 注入攻击——这种问题并非简单的加固就能解决，而是源于架构层面的根本缺陷。

自定义查询类必须强制采用预处理绑定机制

很多开发团队习惯编写一套“通用查询类”，底层却仍然依赖 mysql_query() 或 mysqli_query() 进行字符串拼接，只是在外层简单包装方法名。说实话，这无异于换汤不换药。真正安全的做法是：所有执行入口——例如 select()、update()——内部必须统一调用 prepare() 与 execute()，并且严格禁止开放任何可以直接拼写完整 SQL 语句的接口。

• 类在构造时就应该持有已配置好的 PDO 或 MySQLi 实例，并且该实例必须禁用模拟预处理：PDO::ATTR_EMULATE_PREPARES => false
• 所有来自用户输入的参数——包括 where 条件、limit 数值、order 字段——都必须通过占位符传递，严禁直接在 SQL 字符串中插值拼接
• 如果类中提供了 raw()、expr()、setSql() 这类方法，默认情况下应将其禁用，或者仅允许极少数白名单内的固定语句（例如 "NOW()"）

动态表名与字段名必须经过白名单硬性校验

预处理占位符 ? 和 :name 只能用于数据值，不能作用于标识符——像表名、列名、ORDER BY、GROUP 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() 方法，就必须动态生成对应数量的 ?，并将数组值平铺到参数列表中。

• 错误写法："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() 方法——那整套防护体系就会瞬间归零。