SQL 注入与 WAF 绕过：从规则失配到纵深防御

Sun, 27 Sep 2026 11:40:00 +0800

SQL 注入长期位居 Web 安全风险的核心位置，并不是因为它“古老”，而是因为它直接触碰了应用安全中最根本的一条边界：数据与代码必须分离。

当用户输入被拼接进 SQL 语句时，输入不再只是数据，而有机会改变语句结构。安全产品、输入过滤和 WAF 可以增加攻击成本，但它们不能替代安全的数据访问方式。本文讨论 SQL 注入的主要类型、WAF 绕过的本质、常见检测误区，以及更可靠的工程化防御方案。

本文用于安全开发和防御体系建设。涉及真实系统的测试必须在明确授权、可恢复和可追踪的前提下进行。文章不提供针对真实目标的攻击步骤或可直接复用的绕过 payload。

一、SQL 注入的本质

应用程序通常会根据用户输入构造数据库查询。例如，概念上可能出现这样的逻辑：

查询用户名为输入值的管理员记录

如果输入始终被当作“用户名”这个数据值处理，那么无论用户输入什么内容，它都不应该改变查询结构。但如果应用采用字符串拼接，输入的语义就可能从“值”变成“语法”。

SQL 注入成立通常同时需要三个条件：

第三个条件经常被忽略。没有可观测差异，攻击者通常难以持续判断自己的假设是否正确。因此，防御不只是阻止某个字符，而是同时收紧语法边界、数据库权限、错误输出和日志可见性。

SQL 注入可以有多种分类方式。按照攻击者如何观察结果，通常可以分为以下几类。

部分数据库支持 UNION，它可以把两条查询结果合并到同一结果集中。

联合查询型注入成立的前提通常包括：

UNION 并不会让数据库“忽略权限”。如果数据库账号只能读取一张业务表，即便语句结构被改变，也不可能越过数据库本身的权限边界。

因此，防御不能只关注 UNION 这个关键词，还要确保：

报错型注入依赖应用把数据库错误原样返回给客户端，或者错误信息中包含可观察的表达式结果。

攻击者真正利用的不是“报错”本身，而是：

从工程角度看，生产环境应做到：

即使错误信息不再回显，也不能认为漏洞已经修复。错误隐藏只是降低信息泄漏，不能阻止注入执行。

布尔盲注利用应用状态的差异来推断条件是否成立，例如：