EdgeOne Web 防护×AI 升级：让 AI 既参与攻击识别，也参与误报纠错

一、AI 业务正在改变 Web 防护的精度边界

随着大模型对话、AI 编程助手、AI 客服、AI 搜索等应用大规模上线，用户与系统之间的交互内容越来越接近"代码"——一句正常的请求可能包含 SQL 语法、HTML 片段、命令行结构。传统 Web 防护引擎在面对这类请求时，很容易误判为攻击载荷。

两个真实场景：

场景一：AI 对话接口的误拦

某 AI 大模型平台的对话窗口里，终端用户输入了一段 SQL语句，希望 AI 帮忙优化查询性能。这段请求在到达 AI 推理服务之前，先经过了部署在业务入口的 Web 防护引擎—从语法层面看，输入框里的内容确实是一段可执行的 SQL，命中了规则引擎里的 SQL 注入特征，请求被直接拦截。AI 后端从未收到这条对话，用户在前端看到的是一次失败的请求。

Web 防护并没有判断错；它只是无法判断"这句 SQL 在当前业务上下文中究竟是用户想让 AI 帮忙优化的素材，还是针对该 AI 平台自身数据库的注入攻击"。

场景二：零售采购订单的误拦

一家服装零售企业的供应商在采购系统中提交订单，字段中含 “order by 5-12”——表达"5月12日交货"。这段文本同时匹配 SQL 注入的特征模式（ORDER BY 后跟算术表达式），被规则引擎判定为攻击。

这类误判不是 Bug，是 Web 防护行业当前架构下的结构性代价：

为了拦住越来越复杂的攻击变体，安全引擎引入了语义分析能力。语义引擎泛化能力的提升，伴随着误报率的同步上升。业内对这套架构的实测显示，部分场景下误报率可逼近甚至超过 25%——意味着每四个正常请求中就有一个被误拦。

二、EdgeOne 的做法：让 AI 在两个层面同时参与

EdgeOne 的方案是三层架构：规则引擎 + 自研语义引擎 + 旁路 AI 分析引擎。

第一层：规则引擎独立运行——已知攻击的精准消化

规则引擎是基础层。对已知 CVE 和固定特征攻击，正则匹配是最快最准的手段。

为什么不能跟语义引擎合并？ 把规则匹配和语义分析放在一个模型里同时学，结果是规则匹配的精准度被语义引擎的泛化能力拉低。规则引擎独立运行的工程价值是：把绝大多数已知攻击在第一层就消化掉，让进入语义引擎的流量是"必须靠理解才能判断的部分"——语义引擎在更小的样本空间里工作，精度才能拉满。

第二层：自研语义引擎，按攻击类型独立建模

EdgeOne 采用自研语法级安全检测引擎，核心由 Bison/Flex 语法分析器与自定义语义评分函数组成。Hyperscan 做入口预过滤，Bison/Flex 按攻击类型独立语法文法做解析（SQLi 基于 MySQL 方言子集，XSS 围绕浏览器执行上下文多层解析）。不构建完整 AST，边解析边在 semantic action 中累计安全信号，输出结构化 RiskScore。对 SQL 注入、XSS、命令注入分别独立建模——不用一个通用模型一锅端。

为什么必须独立建模？ SQL 注入和 XSS 在语法层面本质不同：

● SQL 注入关注的是数据库语句的可执行性——引号闭合、UNION 拼接、注释截断、ORDER BY 后的算术结构等

● XSS 关注的是脚本在浏览器的执行链条——标签嵌套、属性注入、事件触发、编码绕过等

● 命令注入又有自己的特征空间——管道、反引号、子shell

用同一个模型同时学这三件事，结果就是三件事都学得不够透。 通用模型必然在每一类上做妥协，每一类攻击的判别精度都做不到极致。EdgeOne 选择对每一类攻击单独建模、单独训练、单独调优——工程更重，但每一类的精度都能拉到上限。

测评数据（内部测评集）：

● 单独语义引擎：拦截率超过 80%，误报率不到 0.1%，旁路 AI 分析引擎上线后，目标将线上误拦截率压至 0.01% 以下

● 规则 + 语义 + 少量加白的综合方案：召回率超过 95%

● 语义引擎能识别规则引擎覆盖不到的48种攻击变体——MSSQL 方言、PG_SLEEP、UNION 变形等。

当前进度：

● SQL 注入：已上线运行

● XSS 跨站脚本：Q3 内上线

● 命令注入：Q3 内上线

● 三大主流 Web 攻击类型全覆盖：Q3 内上线

第三层：旁路 AI 分析引擎——误报纠错与策略自生成

模型再准，也覆盖不了所有客户的业务上下文。语义引擎在训练阶段没见过 “order by 5-12 表达 5月12日交货” 这种业务表达，也没见过用户在 AI 对话接口里随口让 AI 写 SQL 的语境——这些"看起来像攻击但意图完全正常"的请求，会一直留在残留误报里。

EdgeOne 的解法是在前两层引擎之外加一层旁路 AI 分析引擎——不直接拦截流量，对线上实时请求做聚合分析，自动识别两类异常：

● 大范围误拦：多个正常请求被语义引擎误判为攻击

● 定向攻击透传：某种特定攻击手法绕过了语义引擎

发现异常后，AI 分析引擎自动生成修正策略下发回前两层引擎。

这一层的每一个设计都对应一个具体的工程约束：

● 旁路而不是串行运行——如果 AI 分析串行在请求链路上，每个请求都要等推理结束才能响应，业务延迟会无法接受。旁路意味着 AI 分析跟实时拦截是两条独立路径，互不阻塞。

● 聚合分析而不是单点判断——单条请求看不出是误拦还是攻击。order by 5-12 这条字符串孤立来看像 SQL 注入；只有把同业务接口、同时间窗口下的请求一起看，才能从"单条像攻击"变成"一群正常用户的相似行为"。

● 路径级而不是全局加白——给某个业务接口加白等于全局放行，攻击者会立刻找到这个口子去打。把策略限定在具体接口下，这个加白只对该接口的语境生效，其他接口的防护一点不动。

● 即生即消而不是永久策略——业务场景在变。一周前正常的某个用户行为，可能因为业务调整就消失了，固化的策略会变成新的误拦源，甚至可能被攻击者反向利用。AI 分析引擎只在异常场景持续期间维持策略，场景一消失策略立刻撤回。举个反例：某接口因为一次产品功能上线临时加白，三个月后产品下线了，加白策略却还在。攻击者通过历史接口探测发现这个口子，从这条"僵尸通道"打进来。即生即消意味着策略和业务场景绑定：场景消失，策略 24 小时内自动撤回，不留尾巴。

这一层解决的是模型能力之外的问题——模型在训练阶段无法穷举所有客户的真实业务上下文，但聚合后的线上流量里有上下文可读。过去依赖客户安全团队人工处理的误报运维，被自动化了。

该能力全量上线后，目标将线上实际误报率压至万分位以下。

三、回到开头那两个场景

AI 对话接口：接入后，AI 分析引擎从聚合的请求里识别出该接口的语义模式属于正常对话——前后没有引号闭合、没有恶意载荷拼接，自动生成针对该接口的加白策略。其他业务接口的 SQL 注入防护完全不受影响。

零售采购订单：语义引擎结合上下文判断 “order by 5-12” 是日期表达而非 SQL 注入语法，直接放过。

这类场景的共同点：用户输入里含可执行语句的结构，但意图完全正常——是面向 C 端用户、用户输入不可预测的业务最常见的误报场景。

四、谁最需要这次升级

AI 对话与 AI 助手平台——用户与 AI 交互时大量包含可执行语句结构，是最容易触发语义引擎误报的场景。AI 分析引擎根据聚合上下文自动修正。

即时零售 / 电商平台——每个误拦都是一个真实用户无法下单。路径级加白让业务关键路径的误拦自动消除。

Web3 / 区块链平台——用户交互频繁且不可预测，传统全局加白风险高。AI 分析引擎的策略精确到路径和场景。

游戏官网 / 社区——用户在论坛、评论区输入大量含 SQL 关键字、HTML 标签的内容。AI 分析引擎自动处理，不需要人工维护加白规则。

五、下一步

想了解 Web 防护 AI 能力是否适合你的场景？

→ 和方案专家聊聊