防御联合查询注入的核心是参数化查询与白名单校验，因union要求字段数和类型严格匹配，攻击者通过order by和union select试错探测结构，而参数化可彻底隔离用户输入使其无法参与sql解析，动态标识符则必须用白名单控制。
防御联合查询注入，核心是让 UNION 根本无法被数据库当作 SQL 结构执行——不是靠“拦住关键词”，而是从源头切断它被拼接进查询语句的路径。
为什么 ORDER BY 和 UNION SELECT 能探出字段数？
因为数据库在执行 UNION 时会强制校验左右两个 SELECT 的列数是否一致，不一致就报错，比如：SQLSTATE[HY000]: General error: 1222 The used SELECT statements have a different number of columns。攻击者正是靠反复试 ORDER BY 1、ORDER BY 2…直到报错，倒推出原查询字段数。一旦字段数被摸清，UNION SELECT 1,2,3,... 就能精准对齐回显位。
这意味着：任何允许用户输入影响 SQL 结构（如排序、字段数、表名）的地方，都是高危点。
- 动态
ORDER BY子句不支持参数化，必须用白名单控制，例如只接受['id', 'created_at', 'status'] -
LIMIT和OFFSET也不能直接拼接用户输入，否则可能配合盲注提取数据 - 错误页面若暴露数据库报错信息，等于主动告诉攻击者字段数和类型，应统一返回 500 页面，日志另存
预编译参数化查询为何是第一道防线？
参数化不是“过滤输入”，而是把用户数据彻底隔离在 SQL 语法结构之外。数据库收到的永远是：一个已编译好的执行计划 + 一组纯值参数。哪怕你传入 ' UNION SELECT password FROM users--，它也只会被当做一个字符串字面量，不会触发任何 SQL 解析。
不同语言的正确写法差异很大：
- PHP PDO：必须用
prepare()+execute()，且占位符只能用于WHERE、HAVING等值位置，不能用于表名或列名 - Java JDBC：必须用
PreparedStatement，调用setString()等方法赋值，绝不能用Statement拼接 - Node.js pg：必须用参数化查询形式
client.query('SELECT * FROM users WHERE id = $1', [id])，而非模板字符串
常见错误是“伪参数化”：比如先用正则删掉单引号再拼接，或用 mysql_real_escape_string 处理——这些在宽字节、多编码场景下极易绕过。
哪些地方参数化根本不起作用？
表名、列名、排序字段、分组字段、函数名……所有构成 SQL 语法骨架的部分，数据库驱动层根本不支持绑定参数。这时候白名单不是可选项，是唯一解。
- 不要试图“过滤”或“转义”列名，
preg_replace('/[^a-zA-Z0-9_]/', '', $input)会放过user_id，而攻击者可以构造user_id UNION SELECT ...绕过 - 白名单必须基于业务语义定义，比如“允许排序的字段”只限于数据库中真实存在的、有索引的业务字段，不含计算字段或别名
- 如果前端需要按不同字段搜索，应在应用层做映射：用户传
sort=nickname，后端查白名单确认nickname对应数据库字段user_name，再拼进 SQL
最危险的是把白名单逻辑放在前端或 URL 参数里——攻击者改个请求就能绕过。白名单验证必须在服务端入口处完成，且拒绝一切未明确定义的值。
ORM 和框架封装层容易忽略的陷阱
很多开发者以为用了 Laravel Eloquent 或 Django ORM 就自动免疫，其实不然。ORM 只对简单 WHERE 条件默认参数化，但以下操作仍可能引入漏洞：
- 原生 SQL 查询：Laravel 的
DB::select(DB::raw(...))、Django 的extra()或raw()，一旦拼接用户输入即失效 - 动态字段构建：如
->select($userInput)，$userInput 若未经白名单校验，等同于直接拼接列名 - 条件链式调用中的闭包：某些 ORM 允许在
where中传闭包，若闭包内拼接了用户输入，参数化也会失效
真正安全的做法是：只要涉及用户输入参与 SQL 结构生成，无论用什么框架，都必须回归到两个判断——能不能参数化？不能的话，有没有严格白名单？没有，就重构成能支持的形式。
