堆叠查询（Stacked Queries）的本质是在一条数据库访问指令中，利用分号分隔执行多条SQL语句。攻击者一旦找到注入点，就会尝试在原始语句后追加自己的语句，例如在MySQL中构造"1; DROP TABLE users;--"，或者在SQL Server中执行"1; WAITFOR DELAY '0:0:5';--"。这种攻击的破坏力远高于普通的联合查询注入，因为它不依赖页面回显，可以直接完成数据篡改、权限提升、写Webshell甚至执行系统命令。识别堆叠攻击的关键不是看请求里有没有分号，而是看后端数据库驱动是否允许多语句执行，以及WAF或代码层是否对语句分隔符做了有效拦截。

要准确识别堆叠注入，需要理解不同数据库对多语句的支持差异。MySQL的PHP mysqli扩展默认支持多语句，但PDO默认关闭多语句执行；SQL Server的ADO.NET驱动天然支持批处理；PostgreSQL的libpq驱动同样允许多语句。攻击者会针对这些特性调整payload，例如在MySQL中尝试";SELECT SLEEP(5);"，在SQL Server中使用";EXEC xp_cmdshell 'whoami';"。识别阶段应重点监控请求参数中出现的分号、注释符、十六进制编码后的分号（%3B）、双重URL编码（%253B）以及Unicode全角分号等变体。单纯依赖黑名单匹配分号很容易被绕过，因为攻击者可以用"/*!50000;*/"这样的版本注释语法，或者用换行符、制表符替代空格来干扰正则。

堆叠攻击的典型利用场景与危害

堆叠注入最直接的危害是数据破坏。攻击者可以在一条请求中完成“查询-篡改-删除”的组合操作，例如先执行"SELECT"确认表结构，再执行"UPDATE"修改管理员密码，最后执行"DROP"删除审计日志。在SQL Server环境下，如果数据库账号具备"sysadmin"权限，攻击者可以通过"EXEC master..xp_cmdshell"直接执行操作系统命令，进而获取服务器控制权。在MySQL中，即使没有"FILE"权限，攻击者也可以利用"INTO OUTFILE"配合堆叠写入Webshell，前提是知道网站绝对路径且目录可写。另一个容易被忽视的风险是数据外带：攻击者可以通过堆叠执行"SELECT ... INTO OUTFILE '/var/www/html/out.txt'"将敏感数据写入可访问的Web目录，或者利用时间盲注逐字符拖库。

识别堆叠攻击需要从流量特征、语法结构和行为模式三个维度入手。流量特征方面，堆叠payload通常包含分号、多条完整SQL语句、注释截断符（"--"、"#"、"/*"）以及时间延迟函数（"SLEEP"、"WAITFOR DELAY"、"pg_sleep"）。语法结构方面，攻击者会尝试闭合前一条语句的引号或括号，然后追加自己的语句。行为模式方面，堆叠攻击往往伴随异常的时间响应、突发的数据变更或文件系统操作。建议在WAF规则中同时检测以下模式：参数值中出现两个以上SQL关键字（"SELECT"、"UPDATE"、"DELETE"、"INSERT"、"DROP"、"EXEC"、"INTO OUTFILE"），且关键字之间由分号或注释符分隔；参数值中出现";"后紧跟SQL操作关键字；参数值中出现"/*!"或"*/"这类MySQL版本注释。

基于语义分析的堆叠注入识别方法

传统正则匹配对堆叠注入的识别率较低，因为攻击者会使用各种编码和混淆手段。更可靠的方式是对参数值进行SQL语法解析，判断是否包含多条完整的SQL语句。具体实现上，可以在WAF中集成轻量级SQL解析器，对解码后的参数值尝试进行词法分析和语法分析。如果解析结果包含两个或以上的语句节点，且这些语句之间存在分号分隔，即可判定为堆叠攻击。这种方法对编码混淆、注释插入、空白字符替换等绕过手段有较好的鲁棒性。例如，攻击者提交"1';%0aSELECT%0aSLEEP(5);--"，经过URL解码后得到"1'; SELECT SLEEP(5);--"，SQL解析器可以识别出这是一个包含两条语句的堆叠结构。需要注意的是，解析器必须兼容目标数据库的方言特性，否则可能产生误报或漏报。

另一种有效的识别思路是检测参数值中的“语句边界”。堆叠攻击的核心特征是分号前后都存在完整的SQL语法单元。可以通过正则表达式匹配";\s*(SELECT|UPDATE|DELETE|INSERT|DROP|EXEC|DECLARE|SET|CREATE|ALTER|GRANT|REVOKE|INTO)"这样的模式，但需要处理大小写、注释、空白和编码变体。更精细的做法是提取分号后的第一个词法单元，判断它是否属于SQL操作关键字集合。如果分号后是"SELECT"、"UPDATE"等关键字，基本可以确定是堆叠攻击；如果分号后是"--"、"#"或空内容，则可能是注释截断，需要结合上下文进一步判断。对于MySQL特有的"/*!50000;*/"语法，需要单独检测"/*!"后跟数字和SQL语句的模式。

堆叠攻击的拦截策略与代码层防护

拦截堆叠攻击最有效的方法是在数据库驱动层关闭多语句执行能力。对于PHP PDO，确保"PDO::ATTR_EMULATE_PREPARES"设置为"false"，并且使用真正的预处理语句，这样即使参数中包含分号，数据库也会将其作为字面值处理。对于PHP mysqli，避免使用"multi_query"函数，改用"prepare"和"execute"。对于SQL Server，使用参数化查询时，堆叠注入无法生效，因为"SqlCommand"会将参数值作为标量处理。对于Java JDBC，使用"PreparedStatement"同样可以阻止堆叠注入。代码层防护的核心原则是：所有用户输入必须通过参数绑定进入SQL语句，任何字符串拼接SQL的方式都存在堆叠注入风险。

如果业务场景确实需要执行多条SQL语句（例如批量导入、存储过程调用），应当将多语句逻辑封装在数据库存储过程中，通过参数传递用户输入，而不是在应用层拼接SQL。存储过程内部可以使用动态SQL，但必须对输入进行严格的白名单校验和类型转换。对于必须使用动态SQL的场景，建议使用数据库提供的转义函数（如MySQL的"mysql_real_escape_string"）处理单引号，但这只能防止单引号闭合，无法阻止分号注入，因此还需要额外检查输入中是否包含分号，并拒绝包含分号的请求。更安全的做法是使用数据库的预处理语句API，即使需要动态拼接表名或列名，也应当从白名单中选取，而不是直接使用用户输入。

WAF层面的堆叠攻击拦截规则设计

WAF拦截堆叠攻击需要兼顾准确率和性能。建议采用分层检测策略：第一层使用快速正则匹配，过滤明显的堆叠payload，例如";\s*(SELECT|UPDATE|DELETE|INSERT|DROP|EXEC|INTO\s+OUTFILE|LOAD_FILE)"；第二层使用语义分析引擎，对正则匹配命中的请求进行SQL语法解析，确认是否真的包含多条语句；第三层使用行为分析，对短时间内多次触发堆叠规则的源IP进行封禁或挑战验证。正则规则需要覆盖以下绕过手段：URL编码（"%3B"）、双重编码（"%253B"）、Unicode编码（"\u003b"）、注释插入（";//SELECT"）、空白字符替换（";\tSELECT"）、大小写混合（";sElEcT"）。

针对MySQL特有的堆叠绕过，需要重点检测"/*!"版本注释语法。攻击者可以使用"/*!50000;SELECT SLEEP(5);*/"这样的payload，在MySQL 5.0及以上版本中，分号后的语句会被执行，而普通正则可能只看到注释块。WAF规则应匹配"/\*!\d+.*;.*\*/"模式，并对注释块内部的内容进行递归检测。对于SQL Server的堆叠攻击，需要关注"EXEC"、"xp_cmdshell"、"sp_executesql"等危险关键字，以及"WAITFOR DELAY"时间盲注特征。对于PostgreSQL，需要检测"pg_sleep"、"COPY ... FROM PROGRAM"等危险函数。WAF规则还应当对请求参数的长度、特殊字符密度、SQL关键字密度进行统计，堆叠payload通常具有较高的特殊字符比例和多个SQL关键字。

堆叠攻击的日志审计与应急响应

有效的堆叠攻击防护不仅依赖实时拦截，还需要完善的日志记录和事后分析能力。建议在WAF和数据库层同时记录完整的请求内容、解码后的参数值、触发规则ID、源IP、时间戳和响应状态码。对于被拦截的堆叠攻击，日志中应保留原始payload的编码形式和解码后的明文，便于后续分析攻击者的手法和工具。数据库层可以开启查询日志，记录所有执行的SQL语句，但需要注意性能开销和敏感数据脱敏。当发现堆叠攻击成功执行后，应立即检查数据库中的关键表是否被篡改，审计日志是否被删除，以及是否有新增的数据库账号或存储过程。

应急响应的第一步是隔离受影响的系统，切断攻击者的访问通道。然后对比数据库备份和当前数据，找出被篡改的记录。对于SQL Server环境，检查"xp_cmdshell"是否被启用，如果被启用且非业务需要，立即禁用。对于MySQL环境，检查"secure_file_priv"配置，确认"INTO OUTFILE"是否被滥用。同时检查Web目录下是否有可疑的脚本文件，特别是最近修改时间异常的文件。最后，修复注入点，更新WAF规则，并将攻击者的IP和payload特征加入黑名单。堆叠攻击的溯源分析需要结合WAF日志、数据库查询日志和系统日志，还原攻击者的完整操作链路。

堆叠注入的防护不能只依赖单一技术手段。代码层的参数化查询是根本，WAF的语义检测是补充，数据库的权限最小化是兜底。建议数据库账号遵循最小权限原则，应用连接数据库的账号不应具备"DROP"、"CREATE"、"EXEC"、"FILE"等危险权限，即使发生堆叠注入，攻击者也无法执行破坏性操作。对于高权限操作，应当使用独立的运维账号，并通过堡垒机进行审计。同时，定期对应用进行渗透测试和代码审计，重点检查SQL语句拼接点、ORM框架的原始SQL使用情况，以及数据库驱动的多语句配置。只有将识别、拦截、审计和应急响应结合起来，才能形成对堆叠攻击的有效防护体系。