本文详解 WordPress 中自定义 SQL 查询的安全风险，指出仅用 sanitize_text_field() 无法防御 SQL 注入，强调必须结合 wpdb::prepare()、白名单校验及预编译逻辑，提供可直接落地的加固方案与安全示例。
本文详解 wordpress 中自定义 sql 查询的安全风险，指出仅用 `sanitize_text_field()` 无法防御 sql 注入，强调必须结合 `wpdb::prepare()`、白名单校验及预编译逻辑，提供可直接落地的加固方案与安全示例。
在 WordPress 开发中，为满足复杂业务需求（如多维动态筛选、跨表关联或非标准字段查询），开发者常需编写自定义 SQL 查询。但正如示例所示，仅对列名使用 sanitize_text_field() 是严重不安全的——该函数仅过滤 HTML 实体、移除换行符和空字符，无法阻止 SQL 关键字注入或列名上下文逃逸。例如，若 $filter['col_name'] 被恶意构造为 'id OR 1=1 --'，经 sanitize_text_field() 后仍会保留，导致查询逻辑被篡改。
✅ 正确做法：三重防护机制
1. 列名（identifier）必须严格白名单校验
数据库列名属于 SQL 标识符（identifier），不能通过字符串转义处理，必须限定为已知安全值：
// 定义允许查询的列名白名单
$allowed_columns = ['ID', 'post_title', 'post_status', 'post_date', 'menu_order'];
$col_name = strtoupper($filter['col_name']); // 统一大小写便于匹配
if (!in_array($col_name, $allowed_columns, true)) {
throw new InvalidArgumentException('Invalid column name');
}2. 操作符（operator）必须硬编码或白名单限制
禁止用户输入任意操作符，仅允许预设安全值：
Cn Password Generator
下载
安全的随机密码生成器。支持自定义长度、字符类型（大写/小写字母、数字、特殊符号），排除相似字符，批量生成。纯 Python 标准库，无需 API 密钥。
$allowed_operators = ['=', '!=', '>', '<', '>=', '<=', 'LIKE', 'IN', 'NOT IN'];
$operator = strtoupper($filter['operator']);
if (!in_array($operator, $allowed_operators, true)) {
throw new InvalidArgumentException('Invalid operator');
}3. 值（value）必须通过 wpdb::prepare() 参数化绑定
绝不可拼接字符串！ 使用 wpdb::prepare() 进行占位符绑定，确保值被正确转义：
global $wpdb;
// 构建条件子句与参数数组
$where_clauses = [];
$params = [];
foreach ($filters as $filter) {
$filter = (array) $filter;
// 白名单校验列名与操作符（见上）
$col_name = /* ...白名单校验后值... */;
$operator = /* ...白名单校验后值... */;
$value = $filter['value'];
if ($operator === 'IN' || $operator === 'NOT IN') {
// 处理 IN 子句：需动态生成占位符
if (!is_array($value)) {
$value = array_map('intval', explode(',', $value)); // 示例：支持 "1,2,3"
}
$placeholders = implode(',', array_fill(0, count($value), '%d'));
$where_clauses[] = "$col_name $operator ($placeholders)";
$params = array_merge($params, $value);
} else {
$where_clauses[] = "$col_name $operator %s";
$params[] = $value;
}
}
// 组装最终查询（注意：表名仍需白名单校验，不可拼接）
$sql = $wpdb->prepare(
"SELECT * FROM {$wpdb->posts} WHERE 1=1 " . implode(' AND ', $where_clauses),
$params
);
$results = $wpdb->get_results($sql);⚠️ 重要注意事项
- wpdb::prepare() 是核心防线：它等效于 sprintf + esc_sql()，但仅对 %s（字符串）、%d（整数）、%f（浮点）等占位符生效；不可用于列名、表名、操作符。
- 避免第三方包替代原生安全机制：文中提及的 wp-database-model 等 Composer 包虽提供 ORM 抽象，但未改变底层 SQL 安全原则——其本质仍是封装 wpdb::prepare() 和白名单逻辑，不应替代开发者对 SQL 注入原理的理解。
- 启用 WordPress 数据库调试（开发环境）：设置 define('WP_DEBUG', true); define('SAVEQUERIES', true); 可记录原始 SQL，便于审计拼接逻辑。
✅ 总结
安全的自定义查询 = 白名单（列名/操作符） + 参数化（值） + 最小权限（专用 DB 用户）。抛弃字符串拼接思维，拥抱 wpdb::prepare() 与显式校验。WordPress 的安全性不在于“用了某个函数”，而在于是否理解每个输入在 SQL 语法树中的角色——是标识符？是字面量？还是运算符？唯有分层防御，方能杜绝注入风险。
