首页 > 数据库 >PHP自定义查询类防止SQL注入方法

PHP自定义查询类防止SQL注入方法

来源：互联网 2026-07-09 12:32:07

PHP资讯合集

自定义查询类防SQL注入必须强制使用预处理绑定，禁用模拟预处理，占位符仅用于数据值。动态表名需白名单映射，IN语句手动展开占位符。输入验证不能替代预处理，杜绝任何字符串拼接。

在自定义查询类中直接使用字符串拼接构建SQL语句，即便引入addslashes()或mysqli_real_escape_string()进行防护，仍然无法有效阻止SQL注入攻击。这一问题本质上不属于加固范畴，而是架构层面的结构性缺陷。

PHP自定义查询类防止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当用户名拼进另一个查询）。