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

用户跟 AI 说"帮我写段 SQL"——请求被防火墙拦了

最近一个 AI 大模型平台的客户反馈：他们上线新的对话接口后，用户端"请求失败"的反馈量明显增加。

排查了一圈——服务正常，数据库正常，AI 推理正常。

最后定位到一层从来没人怀疑过的东西：Web 防护。

用户对 AI 说"帮我写一段 SQL 查询语句"——这句话从语法上看，确实是一段可执行的 SQL。规则引擎和语义引擎按攻击模式去判断，识别为 SQL 注入，直接拦截。

Web 防护没判断错。它只是没法判断"这句话在当前业务里到底是不是攻击"。

这不是个案

我们另一个客户——一家服装零售企业——遇到过类似的事。

他们的供应商在系统里发起采购时，订单字段里写了 “order by 5-12”，意思是"5月12日交货"。规则引擎识别到 ORDER BY 后跟着算式，判定为 SQL 注入，拦下来了。

共同特征：用户输入里包含"看起来像攻击"的语法结构——但实际意图完全正常。

这件事在 AI 时代变得越来越普遍。AI 对话、AI 客服、AI 编程助手、AI 搜索——用户跟系统的交互内容越来越接近"代码"，传统 Web 防护的精度面临新挑战。

我们的做法：让 AI 既参与识别，也参与纠错

EdgeOne 这次的 Web 防护 AI 升级，做了两件事。

第一件：把语义引擎做成自研模型，按攻击类型独立建模。

SQL 注入、XSS、命令注入分别有独立的语义模型，不是一个通用模型一锅端。为什么不能用一个通用模型一起学？ SQL 注入和 XSS 在语法层面完全不同——前者关注数据库语句的可执行性，后者关注脚本在浏览器的执行链条。同一个模型同时学这两件事，结果就是两件事都学得不够透。EdgeOne 选择对每一类攻击单独建模、单独训练、单独调优——工程更重，但每一类的判别精度都能拉满。

自研语法级安全检测引擎，基于编译器技术（Bison/Flex 语法分析器 + Hyperscan 预过滤 + 语义评分函数）。按攻击类型独立语法文法，边解析边累计安全信号评分。检测依据是明确的语法与语义信号，非统计模型看文本相似度。

在内部测评集上

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

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

🔹 能识别规则引擎覆盖不到的48种变体 —— MSSQL 方言、PS_SLEEP、UNION 变形等。

第二件：在前两层引擎之外，加了一层旁路 AI 分析引擎。

这一层不直接拦流量，对线上请求做聚合分析，自动发现两类异常——大范围误拦、定向攻击透传——然后生成修正策略下发。

这层 AI 的几个设计都是被问题逼出来的：

• 旁路而不是串行——串行会拖业务延迟；旁路才能不影响实时拦截
• 聚合分析而不是单条判断——order by 5-12 单条看像攻击，得把同接口同时间段的请求一起看，才能从"单条像攻击"读出"一群正常用户的相似行为"
• 路径级而不是全局——给某个接口加白等于全局放行，攻击者立刻找到口子；只对该接口生效，才精准
• 即生即消而不是永久——业务在变，固化的策略一周后会变成新的误拦源；场景一消失策略立刻撤回，举个反例：某接口因为一次产品功能上线临时加白，三个月后产品下线了，加白策略却还在。攻击者通过历史接口探测发现这个口子，从这条“僵尸通道”打进来。即生即消意味着策略和业务场景绑定：场景消失，策略24小时内自动撤回，不留尾巴。

回到开头那两个场景：

• AI 对话接口接入后，AI 分析引擎从聚合请求里读出"这是正常对话"，自动给这个接口下发加白策略，其他业务接口的 SQL 注入防护一点不动。
• 那个零售订单字段，语义引擎结合上下文判断 “order by 5-12” 是日期表达，正常放过。

图片

AI 带来的新场景，让 AI 自己来解，Web 防护 × AI 升级即将上线，敬请期待。想了解 Web 防护 AI 能力是否适合你的场景？点击文末「阅读原文」和方案专家聊一聊。

这是 EdgeOne 安全模块与 AI 能力结合的第二步，Bot 管理的 AI 能力也在路上。