1. 什么是堆叠注入
堆叠注入（Stacked Injection）是一种 SQL 注入攻击手法，其核心原理是在一条 SQL 语句结束后，通过分号（;）拼接并执行另一条或多条额外的 SQL 语句。与普通 SQL 注入只能执行单条查询不同，堆叠注入允许攻击者在同一数据库会话中连续执行多条语句，危害更大。
例如，在支持多语句执行的数据库接口中，攻击者输入以下内容：
sql
1; DROP TABLE users; --如果应用程序未对输入进行有效过滤，拼接后的 SQL 可能变成：
sql
SELECT * FROM products WHERE id = 1; DROP TABLE users; --这样，攻击者不仅查询了商品信息，还成功执行了删除用户表的恶意语句。
2. 堆叠注入与普通注入的区别
普通 SQL 注入通常只能影响当前这条查询语句，例如通过 UNION 拼接查询结果、修改 WHERE 条件等，最终目标多为数据窃取。而堆叠注入的关键区别在于：它允许执行任意类型的 SQL 语句，包括 INSERT、UPDATE、DELETE、DROP、CREATE 等，而不仅仅是 SELECT 查询。
| 对比项 | 普通 SQL 注入 | 堆叠注入 |
|---|---|---|
| 可执行语句类型 | 通常仅限 SELECT 查询 | 任意 SQL 语句 |
| 危害范围 | 数据泄露为主 | 可删表、改数据、写文件等 |
| 利用条件 | 较宽松 | 依赖数据库驱动支持多语句执行 |
| 典型场景 | 登录绕过、数据查询 | 提权、破坏、持久化 |
3. 堆叠注入的利用条件
并非所有数据库环境都支持堆叠注入，其成功利用需要满足以下条件：
- 数据库驱动支持多语句执行：例如 PHP 的 PDO 默认允许，而 MySQL 的 mysqli 需要开启相关选项。
- 应用程序未过滤分号：如果代码对输入中的分号进行了过滤或转义，堆叠注入将无法生效。
- 数据库本身支持多语句：SQL Server、PostgreSQL 等通常支持，而部分数据库（如 Oracle 的某些驱动）默认不支持。
4. 堆叠注入的常见危害
一旦堆叠注入成功利用，攻击者可以执行的操作包括但不限于：
- 数据篡改：通过 UPDATE 语句修改数据库中的敏感数据。
- 数据删除：通过 DELETE 或 DROP 语句删除数据表，造成业务中断。
- 写入恶意数据：通过 INSERT 语句向表中插入恶意内容，如伪造管理员账号。
- 调用存储过程：在支持存储过程的数据库中执行危险操作。
- 结合文件操作：在部分数据库（如 MySQL）中，可通过 INTO OUTFILE 写入 WebShell。
5. 堆叠注入的检测方法
在修复漏洞之前，首先需要准确发现堆叠注入的存在。常见的检测方式包括手工测试、自动化工具扫描和日志分析，下面分别介绍。
手工测试：在参数后追加分号并拼接一条无害语句，观察响应是否出现预期变化。例如在商品详情页的 id 参数后输入：
sql
1; SELECT SLEEP(5); --如果页面响应明显延迟约 5 秒，说明数据库执行了第二条语句，很可能存在堆叠注入。也可以尝试在支持多语句的数据库中执行 1; SELECT 1; --，若返回结果包含两条查询的输出，则进一步确认。
自动化工具扫描：使用 sqlmap 等工具可以快速定位注入点。以 sqlmap 为例，检测命令如下：
bash
sqlmap -u "http://example.com/product.php?id=1" --batch --stacked-queries其中 --stacked-queries 参数专门用于测试目标是否支持多语句执行。工具会尝试注入多条语句并观察响应差异，从而判断是否存在堆叠注入。
日志分析：数据库和 Web 应用日志中往往留有攻击痕迹。重点关注以下特征：
- 分号密集的请求：单个参数中出现多个分号，且分号后紧跟 DROP、UPDATE、INSERT 等关键字。
- 注释符组合 ：请求中包含
--、#或/*等注释符，用于截断原 SQL 语句。 - 异常错误信息：数据库返回语法错误或堆栈信息，说明攻击语句已被部分执行。
- 非预期数据变更：日志显示某条 SELECT 查询后紧跟着 UPDATE 或 DELETE 操作，且来源 IP 相同。
综合运用以上三种方式，可以较为全面地发现堆叠注入漏洞。检测确认后，再按照下一节的防御措施进行修复。
为了更直观地对比三种检测方式的差异，下面从检测效率、准确性、适用场景和局限性四个维度进行总结：
| 对比维度 | sqlmap 自动化扫描 | Burp Suite 手工检测 | 纯手工测试 |
|---|---|---|---|
| 检测效率 | 高，可批量扫描多个参数和 URL，自动尝试多种注入载荷 | 中，需人工构造请求并逐个观察响应，但可借助 Intruder 模块半自动化 | 低，需逐参数手动拼接语句并观察响应，耗时较长 |
| 准确性 | 较高，内置多种检测逻辑和指纹识别，误报率相对可控 | 高，检测人员可结合上下文人工判断响应差异，误报率最低 | 较高，但依赖检测人员经验，容易遗漏隐蔽注入点 |
| 适用场景 | 大规模资产盘点、快速定位注入点、自动化渗透测试流程 | 对单个目标进行深入测试、需要结合业务逻辑判断注入点、绕过 WAF 等复杂场景 | 目标数量少、环境受限（如无法安装工具）、需要快速验证某个具体参数 |
| 局限性 | 可能被 WAF 拦截，且对业务逻辑复杂的场景容易产生误报或漏报 | 对检测人员的技术水平要求较高，配置代理和证书等前置步骤较繁琐 | 效率低，且无法覆盖大量参数和复杂注入变体，容易遗漏 |
选择建议：在实际检测中，建议以 sqlmap 等自动化工具作为第一轮快速筛查手段，快速圈定可疑注入点；随后使用 Burp Suite 对可疑点进行人工复核，结合业务上下文确认漏洞真实性并评估危害；对于环境受限或需要快速验证的场景，再辅以纯手工测试。三种方式相互配合，既能保证检测效率，又能降低误报和漏报风险。
5. 堆叠注入的防御措施
下面以 PHP PDO 为例，对比不安全拼接与安全参数化查询的写法差异。
不安全的写法（拼接 SQL）：
php
$id = $_GET['id'];
$sql = "SELECT * FROM products WHERE id = " . $id;
$stmt = $pdo->query($sql);当用户输入 1; DROP TABLE users; -- 时，拼接后的 SQL 变成：
sql
SELECT * FROM products WHERE id = 1; DROP TABLE users; --由于 PDO 默认允许多语句执行，这条恶意语句会被一并执行，造成删表等严重后果。
安全的写法（参数化查询）：
php
$id = $_GET['id'];
$sql = "SELECT * FROM products WHERE id = :id";
$stmt = $pdo->prepare($sql);
$stmt->execute([':id' => $id]);参数化查询将 SQL 语句结构与参数值分离：数据库先编译 SQL 模板，再把参数作为纯数据绑定，而不是拼接到语句中。因此，即使用户输入 1; DROP TABLE users; --，它也会被当作一个普通的字符串值传给 id 字段，而不会被解析为新的 SQL 语句，从而从根源上阻断堆叠注入。
针对堆叠注入，推荐采取以下防御手段：
- 使用参数化查询（Prepared Statement）：这是最有效的防御方式，将 SQL 语句与参数分离，从根源上杜绝拼接注入。
- 限制数据库账号权限：应用程序使用的数据库账号应遵循最小权限原则，避免使用高权限账号连接数据库。
- 过滤危险字符：对输入中的分号、注释符等特殊字符进行过滤或转义。
- 关闭多语句执行：在数据库驱动层面禁用多语句执行功能，从机制上阻断堆叠注入。
- 使用 Web 应用防火墙（WAF）：作为辅助手段，拦截包含恶意 SQL 特征的请求。
为了更直观地对比五种防御手段的差异，下面从防护效果、实现成本、对业务影响和绕过难度四个维度进行总结：
| 对比维度 | 参数化查询 | 限制数据库权限 | 过滤危险字符 | 关闭多语句执行 | 使用 WAF |
|---|---|---|---|---|---|
| 防护效果 | 最强，从根源上阻断 SQL 拼接，可彻底防御堆叠注入 | 较强，即使注入成功也能大幅限制破坏范围 | 较弱，依赖黑名单规则，容易被编码绕过或遗漏变体 | 较强，直接禁用多语句执行，从机制上阻断堆叠注入 | 中等，可拦截已知攻击特征，但无法防御未知变体 |
| 实现成本 | 较低，只需改写 SQL 写法，改动集中在数据访问层 | 较低，通过数据库账号授权即可完成，运维成本可控 | 较低，编写过滤函数即可，但需持续维护规则 | 低，修改数据库驱动或连接配置即可生效 | 较高，需要采购或部署 WAF 设备，并持续调优规则 |
| 对业务影响 | 小，SQL 语义不变，仅改变参数传递方式 | 小，按最小权限授权后，正常业务功能不受影响 | 较大，过度过滤可能误伤合法输入，影响业务功能 | 小，多数业务不需要多语句执行，关闭后无感知 | 较小，但误拦截可能影响正常请求，需谨慎配置 |
| 绕过难度 | 极高，参数与语句结构分离，攻击者无法改变 SQL 语义 | 较高，即使注入成功，低权限账号也无法执行高危操作 | 低，可通过编码、大小写、注释符等方式绕过过滤 | 高，多语句执行被禁用后，堆叠注入直接失效 | 中等，攻击者可尝试绕过 WAF 规则或利用逻辑缺陷 |
推荐组合方案：在实际防御中，应以参数化查询作为第一道也是最重要的防线，从根源上杜绝 SQL 拼接；同时关闭数据库驱动的多语句执行功能，从机制上阻断堆叠注入；再配合最小权限原则限制数据库账号，即使攻击者突破前两道防线，也无法执行删表等高危操作。过滤危险字符和 WAF 可作为辅助手段，用于纵深防御和拦截已知攻击特征，但不应作为主要依赖。整体遵循「参数化查询为主、关闭多语句执行为辅、最小权限兜底、过滤与 WAF 补充」的组合策略，才能构建多层次的堆叠注入防御体系。
6. 总结
堆叠注入是 SQL 注入中危害较大的一种攻击手法，其本质是利用数据库对多语句执行的支持，在一条 SQL 后拼接恶意语句。防御的核心在于使用参数化查询、最小化数据库权限以及关闭不必要的多语句执行能力。开发者在编写数据库交互代码时，应始终将输入校验和参数化查询作为默认实践，而不是依赖黑名单过滤。