为何堆叠查询在某些SQL环境危害极大

在SQL注入的诸多变种中，堆叠查询（Stacked Queries）无疑是最令人头疼的一种。普通注入通常只能读取数据或导出库表，而堆叠查询却直接允许在单次请求中嵌入多条SQL语句——删除表、插入数据、修改权限，几乎无所不能。关键在于，只要后端驱动支持多语句执行，这种攻击方式几乎无法通过简单的输入过滤来彻底根除。

堆叠查询能执行 DROP/INSERT/UPDATE 等写操作

相比普通 SQL 注入（比如 UNION 或盲注）通常只能读取数据，堆叠查询允许在一次请求中同时执行多条语句。举个例子，攻击者提交 '; DROP TABLE users; -- 或者 '; INSERT INTO admins VALUES ('hacker', 'pwd'); --，只要后端采用了 mysqli_multi_query() 或者设置了 PDO::MYSQL_ATTR_MULTI_STATEMENTS = true 这类支持多语句的驱动配置，数据库就会按顺序逐一执行——先查询，再删除，再插入，完全不受应用层逻辑的约束。

MySQL 默认不启用多语句，但 PHP 驱动常被误配

MySQL 服务端本身默认只接受单条语句，真正打开堆叠大门的其实是客户端驱动的行为。具体来说：

• mysqli_query() 遇到分号会直接报错：MySQLi SQL syntax error
• mysqli_multi_query() 是唯一默认允许堆叠的函数，而且不会对第二条语句进行合法性校验
• PDO 默认禁用多语句，但若显式设置 PDO::MYSQL_ATTR_MULTI_STATEMENTS => true，风险立刻卷土重来

很多旧项目在初始化 PDO 时没有关闭这个标志，或者直接使用 mysqli_multi_query() 进行批量操作，结果就是把注入入口从“只读”升级成了“可写可删”。

WAF 和输入过滤根本挡不住堆叠查询。分号（;）看似容易拦截，但攻击者拥有大量绕过手段：URL 编码用 %3B 替代 ;、通过注释混淆写成 ;/**/DROP/**/TABLE，甚至还能绕开非 HTTP 接口直连数据库——比如 CLI 脚本、定时任务、管理后台 API，这些场景 WAF 根本不覆盖。真正有效的防线只有一条：在建立连接的那一刻就切断驱动执行多语句的能力——不是过滤输入，而是让驱动根本不允许执行多条语句。

修复后容易忽略的兼容性问题

禁用 mysqli_multi_query() 或关闭 PDO::MYSQL_ATTR_MULTI_STATEMENTS 之后，部分旧逻辑会直接崩溃，而不是静默降级。比如安装脚本中原本使用堆叠查询来建表并插入初始数据，会报错：Cannot execute queries while other unbuffered queries are active。再比如 CMS 初始化流程依赖一次发送多条 DDL 语句来建库，失败后日志里可能只记录一句“DB init failed”，完全不提示具体原因。这类调用往往不在主业务链路上，排查时很容易被当成环境问题跳过，但实际上正是堆叠禁用后的必然表现。