防御Union Select SQL注入：检查查询列数固定性

如何有效防御针对Union Select的SQL注入攻击

在防御UNION SELECT注入攻击时，一种常见的思路是检查查询返回的列数是否固定。然而，这一方法存在根本性缺陷：当攻击者能够成功执行ORDER BY 1或UNION SELECT NULL等探测语句时，注入实际上已经发生，列数信息可能已通过报错或页面差异泄露。因此，防御的核心不应是事后检测列数变动，而应从根本上阻止攻击者进行列数探测。关键在于彻底杜绝用户输入影响SQL语句结构的可能性。

真正有效的防御在于杜绝SQL结构的可塑性：必须采用参数化查询（如MySQLi prepare+bind_param、PDO并禁用模拟预处理），禁止字符串拼接；动态字段与排序需严格进行白名单校验；关闭错误回显，避免依赖关键词过滤等事后补救措施。

采用参数化查询消除结构可塑性

问题的根源在于“字符串拼接”。只要用户输入能直接拼入SQL语句，列数探测便成为可能。例如，PHP代码若写作$sql = "SELECT name FROM users WHERE id = " . $_GET['id']，攻击者传入1' ORDER BY 2--即可能触发数据库报错，逐步摸清列数。参数化查询机制正是为此设计：它将SQL语句结构（如SELECT字段、FROM表名）与传入值（如WHERE id = ）在编译时分离。用户输入仅作为“值”被绑定，无法改变SELECT子句的字段数量或查询执行计划。

• MySQLi：务必使用prepare()配合bind_param()方法。仅使用mysqli_real_escape_string()进行转义远远不够，无法防止结构注入。
• PDO：同样使用prepare()与bindValue()或bindParam()。关键点在于确保禁用模拟预处理（设置PDO::ATTR_EMULATE_PREPARES => false），否则PDO可能在客户端模拟预处理，实质上退化为不安全的字符串拼接。
• ORM框架：如Laravel Eloquent、Django ORM等现代框架，默认生成的查询通常是参数化的。但在手动编写原生SQL时，仍需保持警惕，显式进行参数绑定，例如：DB::select("SELECT * FROM users WHERE id = ", [$id])。

避免依赖“检测列数变动”等运行时补救

部分方案试图在应用层拦截包含ORDER BY的请求，或统计UNION SELECT后的逗号数量。这类方法属于“事后补救”，不仅可靠性低，且极易被绕过。

首先，基于规则（如WAF）的检测难以应对order%20by、un/**/ion、sel/*abc*/ect等利用注释、空白符或编码的变体攻击。其次，一旦数据库原始报错信息（如SQLSTATE[HY000]: General error: 1222 The used SELECT statements have a different number of columns）直接返回前端，列数信息便已泄露。攻击者仅凭错误信息即可完成探测。

• 错误处理：生产环境不应直接输出数据库详细错误。应统一返回通用错误页面，并将详细错误记录至服务器日志供开发排查。
• 环境配置：开发环境可开启display_errors以便调试，但生产环境必须关闭此选项，并配置log_errors将错误导向日志文件。
• 关键词过滤的局限性：任何在请求层过滤UNION、SELECT、NULL等关键词的方案，均难以应对大小写混写、注释符分割、编码等绕过手法。依赖此类过滤会带来虚假的安全感。

动态列场景需使用白名单控制结构

业务中确实存在需要动态决定查询字段的场景，如灵活的报表导出功能允许用户勾选导出列。此时，“检查列数是否固定”的逻辑仍不适用。正确做法是放弃对“固定”的检查，转而严格控制“结构”来源——仅允许SQL结构从预定义的安全集合中生成。

• 字段名白名单：所有动态字段名必须经过白名单校验。例如，使用in_array($field, ['id', 'name', 'email', 'created_at'])确保用户仅能选择允许的字段。
• 排序字段同样处理：ORDER BY子句后的字段名和排序方向（ASC/DESC）也必须使用白名单机制，严禁直接拼接用户输入字符串。
• 结构部分硬编码：对于表名、列名等无法使用参数化绑定的SQL结构部分，其来源绝不能是用户请求（GET/POST）。应来自代码硬编码或受信任的配置中心。
• 组合使用：即使使用白名单生成动态字段列表，查询主体部分（如WHERE条件）仍应使用参数化查询。注意，类似SELECT :fields FROM users WHERE status = 的写法（试图将字段列表作为参数绑定）在标准SQL中通常无效。正确模式是：用白名单生成字段列表字符串，再与使用参数化绑定的WHERE条件部分拼接成完整SQL语句。

最后，一个易被忽略的细节是：许多开发者认为“使用PDO即安全”，却未检查是否禁用了模拟预处理，或在处理动态字段、表名时不自觉地回归字符串拼接。防御UNION注入乃至所有SQL注入的精髓，不在于增加检测与过滤层数，而在于确保每条发送至数据库的SQL语句结构在代码编译期即完全确定，不会因任何用户输入产生分支或变化。这才是治本之策。