怎样防御基于UNION的SQL注入攻击_验证查询结果集的字段数量与类型-SQL-PHP中文网

union注入需匹配字段数量和类型，因数据库执行时会隐式列对齐，字段数不等报错，类型不兼容导致转换失败；攻击者通过order by和union select试错探测结构；防御核心是参数化查询与白名单校验。

怎样防御基于union的sql注入攻击_验证查询结果集的字段数量与类型

为什么UNION注入必须匹配字段数量和类型

因为数据库执行 UNION 时会做隐式列对齐：左右两个查询的字段数必须一致，否则报错如 SQLSTATE[HY000]: General error: 1222 The used SELECT statements have a different number of columns；同时，对应位置的字段类型需兼容（比如不能把字符串和日期直接并列），否则可能触发类型转换失败或空结果。

攻击者正是靠反复试错 ORDER BY n 和 UNION SELECT 1,2,3... 来探出真实查询的字段数和大致类型。防御的第一道防线，就是不让这个探针生效。

用预编译参数化查询彻底隔离用户输入

绝大多数 UNION 注入发生在拼接 SQL 字符串的场景，比如 PHP 中的 $sql = "SELECT name FROM users WHERE id = " . $_GET['id']。只要改用参数化查询，用户输入就永远进不了 SQL 结构层，UNION 根本没机会被解析为关键字。

MySQLi：用 prepare() + bind_param()，参数只作为值，不参与语法构建
PDO：用 prepare() + execute()，占位符 ? 或 :name 不会被解释为 SQL 片段
切忌在 WHERE、ORDER BY、GROUP BY 等子句中参数化——这些位置不支持参数绑定，必须白名单校验或重写逻辑

对动态列名/表名等无法参数化的部分做严格白名单控制

当业务真需要动态指定排序字段（如 ORDER BY ? 不合法），就必须放弃自由输入，只允许从预设集合中选：['id', 'name', 'created_at']。任何不在列表中的值直接拒绝，不尝试“智能过滤”或正则替换。

常见错误是用 preg_replace('/[^a-zA-Z0-9_]/', '', $input) 清洗，这仍可能留下 user_id 这类合法字段名，但若后端逻辑又拼接了额外条件（如 "AND status = 1"），攻击者可构造 user_id UNION SELECT ... 绕过。

白名单必须基于语义，而非字符集：比如排序字段只接受已知索引列，且不包含计算字段或别名
若需支持多语言字段别名，应在应用层映射，而非将别名透传到 SQL
绝不信任客户端传来的任何结构相关字段，包括分页参数中的 limit、offset，它们虽不触碰字段数，但配合 UNION 可用于盲注数据提取

应用层验证查询结果集结构（仅限ORM或封装层）

这不是通用防御手段，仅适用于你完全控制查询执行路径的场景，比如自研 DAO 层或重度封装的 ORM。可以在执行前检查 SQL AST 或执行后校验元数据：

执行 SELECT * FROM ... 后调用 mysqli_fetch_fields() 或 PDOStatement::getColumnMeta()，确认返回字段数与预期一致（如业务明确只需 3 列，结果却有 5 列就告警）
对字段类型做粗略检查：比如预期全是 STRING 和 INT，却出现 BLOB 或 NULL 占位，可能是 UNION SELECT NULL,NULL,... 的痕迹
注意：这种校验无法防止注入本身，只能辅助发现异常行为；且 getColumnMeta() 在 MySQL 中部分版本不返回准确类型，PHP 8.1+ 才较可靠

真正有效的防御永远落在输入处理层——字段数和类型匹配只是攻击链上的一环，盯住源头比补救末端更省力也更可靠。别让验证逻辑变成新攻击面。