防止UNION注入的核心是使用参数化查询，通过预处理语句将用户输入作为数据而非SQL代码处理，从而彻底阻断注入路径。
防止PHP中的UNION注入，核心在于永远不要将用户输入直接拼接进SQL查询字符串中，而是要使用参数化查询（预处理语句）。这是最直接、最可靠的防御手段，它能确保用户输入的数据只被当作数据处理，而不会被解释为SQL代码的一部分，从而彻底堵死UNION注入的路径。
UNION注入攻击防护措施
说实话，每次聊到SQL注入，我脑子里首先浮现的总是那些年踩过的坑，以及后来对预处理语句的“真香”体验。UNION注入，本质上是SQL注入的一种变体，它利用了
UNION或
UNION ALL操作符来合并来自不同查询的结果集。攻击者通过注入恶意的
SELECT语句，尝试从其他表中窃取数据，或者执行其他非法的数据库操作。
在PHP中，要有效防止这类攻击，最根本且几乎是唯一的解决方案就是使用数据库抽象层（如PDO）或MySQLi扩展提供的预处理语句（Prepared Statements）。
立即学习“PHP免费学习笔记（深入）”；
这是因为预处理语句的工作原理是，你先定义好一个SQL查询模板，其中用占位符（如
?或命名参数
:param）来代替将来要传入的值。然后，你再将用户输入的数据单独绑定到这些占位符上。数据库服务器在接收到查询模板时，会先对其进行编译和优化，识别出哪些是SQL结构，哪些是数据占位符。当实际数据传入时，它只会被当作纯粹的数据处理，无法改变查询的结构。
以PDO为例，一个正确的防范UNION注入的代码片段大概是这样的：
setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
// 假设用户输入了一个ID
$userId = $_GET['id'] ?? '';
// 这是一个安全的查询示例
// 注意，这里$userId被当作参数绑定，而不是直接拼接到SQL中
$stmt = $pdo->prepare("SELECT name, email FROM users WHERE id = :id");
$stmt->bindParam(':id', $userId, PDO::PARAM_INT); // 明确指定参数类型很重要
$stmt->execute();
$results = $stmt->fetchAll(PDO::FETCH_ASSOC);
foreach ($results as $row) {
echo "Name: " . htmlspecialchars($row['name']) . ", Email: " . htmlspecialchars($row['email']) . "
";
}
} catch (PDOException $e) {
// 在生产环境中，不应直接暴露错误信息
error_log("Database error: " . $e->getMessage());
echo "An error occurred. Please try again later.";
}
?>这里，
$userId无论包含什么，比如
'1 UNION SELECT @@version, NULL'，都会被数据库服务器视为一个完整的字符串值，而不是SQL关键字，从而避免了注入。
为什么传统的字符串拼接方式会带来UNION注入风险？
当我们谈论传统的SQL查询方式，通常指的是直接将用户输入变量嵌入到SQL查询字符串中，就像这样：
$query = "SELECT * FROM products WHERE category = '" . $_GET['category'] . "'";这种做法简直是在给攻击者铺红毯。
当用户输入的数据被直接拼接到SQL语句中时，数据库无法区分哪些是预期的SQL代码，哪些是用户提供的数据。如果攻击者在
$_GET['category']中输入了类似
'electronics' UNION SELECT username, password FROM users --这样的字符串，那么最终执行的SQL语句就会变成：
SELECT * FROM products WHERE category = 'electronics' UNION SELECT username, password FROM users --'
这里的
--是SQL注释符，它会把原查询中
WHERE子句后面可能存在的其他条件注释掉。结果就是，数据库会执行两个独立的
SELECT查询并将它们的结果合并。攻击者原本想查询产品分类，却成功地查询了用户表中的用户名和密码。这种风险的根本原因在于，应用程序没有正确地将数据和代码分离，导致用户输入的数据被错误地解析为可执行的SQL代码。
除了预处理语句，还有哪些辅助措施可以提升数据库安全？
虽然预处理语句是防止UNION注入的黄金法则，但就像任何安全策略一样，单一的措施往往不够。构建一个健壮的数据库安全体系，需要多层次的防护。
最小权限原则（Least Privilege Principle）：给数据库用户分配他们完成工作所需的最低权限。例如，一个Web应用的用户可能只需要对某些表有
SELECT
,INSERT
,UPDATE
,DELETE
权限，而不需要DROP TABLE
,GRANT
,FILE
等高危权限。这样即使发生注入，攻击者能造成的损害也极其有限。我见过太多项目直接用root用户连接数据库，这简直是自掘坟墓。严格的输入验证和过滤：尽管它不能完全阻止SQL注入（因为合法的输入也可能被注入利用），但对输入进行严格的类型检查、长度限制、白名单过滤等，可以减少许多其他类型的攻击面，并使某些注入尝试变得更困难。比如，如果一个ID字段预期是整数，就应该强制转换为整数类型。
Web应用防火墙（WAF）：WAF可以在应用层之前对HTTP请求进行过滤和检测。它能够识别并阻止许多常见的攻击模式，包括SQL注入尝试。虽然WAF不是万能的，但它能提供额外的防御层，尤其是在面对零日漏洞或应用程序尚未修补的漏洞时。
错误信息管理：在生产环境中，绝不应该直接将数据库错误信息显示给用户。详细的错误信息往往包含数据库结构、表名、字段名等敏感信息，这些信息可能被攻击者用来构造更精确的注入语句。应该记录错误日志，并向用户显示一个通用的、友好的错误提示。
定期安全审计和代码审查：定期审查代码，特别是与数据库交互的部分，是发现潜在漏洞的关键。自动化工具可以帮助识别一些常见的模式，但人工审查结合安全专家的经验往往能发现更深层次的问题。
如何识别并测试PHP应用中潜在的UNION注入漏洞？
识别和测试UNION注入漏洞，需要从攻击者的角度思考。这通常涉及构造特定的输入，观察应用程序的响应。
观察错误信息：首先，尝试输入一些明显的错误SQL语法，比如在参数后面加一个单引号
'
。如果应用程序直接将数据库错误信息返回到页面上，那么恭喜你，你可能发现了一个信息泄露点，并且应用程序很可能存在注入漏洞。这些错误信息会告诉你数据库的类型、版本，有时甚至暴露查询语句的一部分，为后续的注入攻击提供线索。利用
ORDER BY
推断列数：UNION注入的前提是两个SELECT
语句的列数必须一致。攻击者会通过ORDER BY
子句来猜测原始查询的列数。例如，尝试?id=1 ORDER BY 10 --+
，如果报错，就减少数字，直到不报错。一旦确定了列数，就可以开始构造UNION SELECT
语句。构造
UNION SELECT
语句：一旦确定了列数，就可以构造UNION SELECT
语句来探测数据。例如，如果原始查询有3列，可以尝试?id=1 UNION SELECT 1,2,3 --+
。攻击者会替换这些数字为数据库函数（如version()
,database()
,user()
）或从其他表中查询数据。例如，?id=1 UNION SELECT null, username, password FROM users --+
。-
基于布尔盲注和时间盲注：如果应用程序没有直接返回错误信息，或者页面内容没有明显变化，攻击者可能会转向盲注技术。
-
布尔盲注：通过构造条件语句（如
AND 1=1
和AND 1=2
），观察页面内容是否发生变化（例如，页面是否显示或隐藏了某些内容），来判断注入语句的真假。 -
时间盲注：当布尔盲注也无效时，可以利用数据库的延时函数（如
SLEEP()
）来判断条件是否为真。例如，?id=1 AND IF(SUBSTRING(VERSION(),1,1)='5', SLEEP(5), 0) --+
。如果页面延迟了5秒才加载，说明条件为真。
-
布尔盲注：通过构造条件语句（如
使用自动化工具：像SQLMap这样的自动化工具，可以极大地简化SQL注入漏洞的发现和利用过程。这些工具能够自动识别注入点，并尝试各种注入技术（包括UNION注入、盲注等），甚至可以自动枚举数据库结构和导出数据。当然，作为开发者，我们更应该关注如何编写安全的代码，而不是仅仅依赖工具去发现漏洞。
总而言之，防御UNION注入并非什么高深莫测的技术，它回归到了最基本的安全实践：数据与代码分离。一旦你养成了使用预处理语句的习惯，并辅以其他安全措施，你的PHP应用在面对这类攻击时，就会变得异常坚固。
