SQL注入的堆叠查询注入与多语句禁止

SQL注入攻击发展到今天，单纯的联合查询注入在很多实战场景下已经显得力不从心。当应用使用参数化查询或预编译语句处理了主要的查询逻辑，攻击者往往会把目光转向那些被开发者忽略的角落。堆叠查询注入就是一把在这种场景下打开突破口的钥匙，它利用的是数据库驱动对多语句执行的支持，而与之对抗的“多语句禁止”策略，正是防御体系中的一道关键防线。

堆叠查询注入的本质，是攻击者能够在原有SQL语句的结尾，通过分号分隔，追加并执行一条或多条完全独立的SQL语句。这与经典的联合查询注入有本质区别。联合查询是通过UNION关键字将攻击者的查询结果拼接到原查询的结果集中，它受限于原查询的列数和数据类型。而堆叠查询则完全跳出了这个限制，后续的语句可以是UPDATE、INSERT、DELETE、DROP甚至是调用存储过程，几乎没有任何操作限制。

一个典型的堆叠查询注入点看起来是这样的：假设后端代码直接将用户输入拼接到查询语句中，例如原本的查询是 SELECT * FROM products WHERE id = '用户输入' 。攻击者输入的参数如果是 1'; DROP TABLE users; -- ，最终数据库执行的语句就变成了：

SELECT * FROM products WHERE id = '1'; DROP TABLE users; --'

分号后面的DROP TABLE users语句会被数据库引擎当作一个全新的语句来解析和执行。这种攻击一旦成功，其破坏力远超数据窃取，可以直接对数据库结构和内容进行毁灭性打击。

堆叠查询能否成功，第一关取决于数据库本身是否支持多语句执行。在主流数据库中，Microsoft SQL Server和PostgreSQL对堆叠查询的支持非常直接且普遍。这也是为什么针对ASP.NET或与SQL Server搭配的PHP应用，堆叠注入往往成为攻击利器。MySQL的情况则稍显复杂，虽然MySQL本身支持多语句查询，但在PHP中，使用老旧的mysql_query函数时，它明确禁止在一次调用中执行多条语句，这在一定程度上提供了原生保护。然而，一旦开发者改用mysqli扩展中的mysqli_multi_query函数，或者使用PDO并错误地配置了模拟预处理，多语句执行的大门就重新敞开了。Oracle数据库则因其架构和PL/SQL的严格性，通常不直接支持这种简单的分号分隔的多语句执行，但这不代表绝对安全，攻击者可能会转向利用存储过程的漏洞。

第二关是应用与数据库之间的连接驱动或库的配置。很多现代的数据库抽象层和ORM框架，出于安全和性能的考虑，默认会禁止在一次请求中发送多条SQL语句。但问题往往出现在那些遗留系统、自行编写的数据库操作类，或者为了处理某些复杂的业务逻辑（如批量导入、执行数据库脚本）而特意开启多语句支持的地方。这些特殊场景就是堆叠查询注入的温床。

“多语句禁止”是一种在数据库连接驱动或网关层面实施的配置策略。它的工作原理很简单：在接收到应用程序发来的SQL语句字符串后，在执行之前，先进行语法解析或简单的模式匹配，检测其中是否包含语句分隔符（通常是分号），如果发现有多条语句的迹象，就直接拒绝执行并抛出异常。这种防御措施非常高效，能从根本上阻断绝大多数堆叠查询注入攻击。

然而，多语句禁止并非万能的银弹。它的局限性体现在几个方面。首先，它可能被绕过。攻击者可以尝试利用分号的多种编码形式，或者利用数据库特有的语句分隔符差异。更关键的是，多语句禁止只能防御堆叠查询这种特定类型的注入，对于经典的联合查询注入、布尔盲注、时间盲注以及报错注入完全无能为力。如果一个应用仅仅依靠多语句禁止来防注入，而其他注入点依然存在，那么攻击者照样可以绕过它来窃取数据。其次，某些业务逻辑确实需要执行多条语句，比如创建临时表再查询，或者在一个事务中执行多个更新操作。如果粗暴地全局禁止多语句，这些功能就会失效。开发者可能会因此被迫寻找变通方案，甚至关闭这个安全设置，反而带来更大风险。

在实战中，当遇到一个明确存在注入但无法使用联合查询的点，并且数据库是支持堆叠查询的，攻击者的思路会立刻打开。一个经典的利用方式是，如果Web应用没有直接回显数据，但攻击者可以通过堆叠执行INSERT语句，将查询结果插入到自己可控的一张表中，然后再通过其他正常功能读取这张表。例如：

1'; INSERT INTO attack_log (output) VALUES ((SELECT group_concat(table_name) FROM information_schema.tables WHERE table_schema=database())); --

这种手法将盲注变成了显注，极大地提高了数据窃取的效率。另一个高级技巧是利用堆叠查询调用数据库的扩展功能。在SQL Server中，如果xp_cmdshell存储过程未被禁用，攻击者可以直接执行系统命令：

1'; EXEC xp_cmdshell 'net user hacker password123 /add'; --

这已经将攻击从数据库层面提升到了操作系统层面，危害性呈指数级上升。在MySQL中，攻击者可能会尝试通过SELECT ... INTO OUTFILE来写入Webshell，但这条语句通常需要堆叠查询的上下文来先绕过一些限制或构造更复杂的文件内容。

面对堆叠查询注入，正确的防御思路不是孤立地开启某个开关，而是构建一个分层的纵深防御体系。最核心、最根本的措施永远是使用参数化查询和预编译语句。无论用户输入什么，参数化查询都能确保输入的内容被严格当作数据值处理，而不是可执行的代码。在参数化查询的保护下，任何试图通过分号注入额外语句的尝试都会失败，因为分号本身会被当作一个普通的字符值来处理。这是解决SQL注入问题的根本之道，也是防御堆叠查询最彻底的方法。

在参数化查询无法覆盖的极少数场景，比如需要动态指定排序的列名或表名时，必须使用白名单校验。将用户输入与预先定义好的、合法的列名或表名集合进行严格比对，任何不在白名单内的输入一律拒绝。绝对不要试图通过黑名单过滤分号等特殊字符来防御，这种方法的对抗性极差，很容易被大小写混合、编码、注释符插入等方式绕过。

数据库连接库的配置可以作为第二道防线。在使用PHP的PDO时，务必禁用模拟预处理模式，并将错误模式设置为抛出异常。正确的配置如下：

$pdo = new PDO($dsn, $user, $pass, [
    PDO::ATTR_EMULATE_PREPARES => false, // 关闭模拟预处理，使用数据库原生的预处理
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
    PDO::MYSQL_ATTR_MULTI_STATEMENTS => false // 明确禁止多语句执行
]);

在SQL Server或PostgreSQL的连接字符串中，通常也都有相应的选项来限制多语句执行，尽管它们默认行为可能不同，但显式地设置禁用选项是一个良好的安全习惯。数据库权限最小化原则同样至关重要。用于Web应用的数据库账户，只应被授予其业务逻辑所必需的最低权限。例如，一个普通的查询展示页面，其数据库连接账户绝不应该拥有DROP TABLE、CREATE TABLE、执行xp_cmdshell或写入文件的权限。即使攻击者找到了堆叠注入点，权限限制也能极大地压缩其攻击面，将潜在的灾难性后果限制在一个可控范围内。

最后，部署Web应用防火墙（WAF）可以作为一种有效的补充性防护和入侵检测手段。配置得当的WAF能够识别并拦截请求中包含的多语句注入特征，为后端应用增加一层缓冲。但必须清醒地认识到，WAF是基于规则和模式匹配的，它可能被高级攻击者绕过，因此绝不能替代代码层面的安全修复。

理解堆叠查询注入，不仅仅是为了掌握一种攻击技术，更是为了深刻理解防御的薄弱点在哪里。多语句禁止是一种有效的缓解措施，但它是一个战术层面的补丁，而非战略层面的解决方案。真正的安全来自于在软件开发生命周期的早期就引入安全设计，将参数化查询作为不可动摇的编码规范，将最小权限作为数据库管理的铁律。当攻击者尝试用分号来分割你的SQL语句时，最坚固的防线不是去检测那个分号，而是确保你的系统从一开始就不把任何用户输入当作代码来执行。这种思维上的转变，才是应对所有类型SQL注入攻击的终极答案。