从正则匹配到意图理解:SafeLine WAF 如何使用语义分析

发布: (2025年12月17日 GMT+8 15:44)
7 min read
原文: Dev.to

Source: Dev.to

基于正则表达式的 WAF 实际做了什么

大多数传统 WAF 依赖 正则表达式 来检测攻击。规则可能是这样的:

union[\w\s]*?select

含义: 如果流量同时包含 unionselect,则将其标记为 SQL 注入。

或者用于 XSS:

\balert\s*\(

含义: 如果输入中出现 alert(,则视为 XSS。

这种做法简单且快速,这也解释了为什么 ModSecurity 等引擎会如此流行。即使在今天,仍有大量 WAF 是基于这种模型构建的。
但简易性是有代价的。

为什么基于正则的检测在实际中会失效

1. 攻击者是对抗性的

真正的攻击者不会为你的正则规则编写负载,他们编写负载是为了绕过它们。

原始规则

union[\w\s]*?select

绕过

union/**/select

同样的 SQL 语义,但关键字模式被破坏了。

原始规则

\balert\s*\(

绕过

window['\x61lert']()

浏览器可以正常执行它,正则永远不会匹配到 alert(

2. 正则导致大量误报

正则规则不理解含义,它们只匹配模式。

示例(SQL)

The union select members from each department to form a committee.

这是一段普通的英文,但它匹配到了 union + select,因此可能被拦截为 SQL 注入。

示例(XSS)

Her down on the alert (for the man) and walked into a world of rivers.

正常的文本,却仍会触发一个天真的 XSS 规则。

结果

  • 真正的攻击仍然可以通过
  • 合法用户被拦截
  • 工程师花时间调规则,而不是解决根本原因

这就是为什么基于正则的 WAF 常常感觉在两个方向上都永远是错的

在 WAF 环境中语义分析的意义

语义分析并不问:

“这个输入看起来像攻击吗?”

相反,它会问:

“这个输入作为可执行逻辑是否合理,如果是的话,它想要做什么?”

SafeLine WAF 正是基于这一理念构建的。

通过语义视角看 SQL 注入

要构成真实的 SQL 注入,必须满足两个条件

1. 输入必须是有效的 SQL(语法上)

有效的 SQL 片段

union select username from users where

无效的 SQL 片段

union select username from users users users where

如果它无法被解析为 SQL,则不可能是 SQL 注入——即使关键字看起来再可疑也不行。

2. SQL 必须具有恶意意图

union select password from users

显然是恶意的。

1 + 1 = 2

有效的 SQL,但从攻击的角度来看毫无意义。

语义分析能够区分这两者。

SafeLine WAF 语义检测攻击方式

  1. 解析 HTTP 请求 并定位所有用户可控输入。
  2. 递归解码 有效负载(URL 编码、Unicode、Base64、混淆等)。
  3. 识别语言上下文(SQL、JavaScript、HTML、模板语法等)。
    • 使用了解语言的解析器/编译器解析输入。
  4. 分析语义意图(数据泄露、代码执行、上下文逃逸)。
  5. 根据真实攻击行为对威胁进行评分
  6. 基于风险而非关键词进行放行或阻断

SafeLine 不仅仅匹配字符串——它 理解结构和意图

为什么语义分析在根本上比正则表达式更强

这不仅仅是个人观点,而是有计算机科学依据的。

一个简短的编译原理小插曲

根据 Chomsky 层级,形式语言被划分为四类:

类型文法识别方式
0Unlimited(无限制)Turing Machine(图灵机)
1Context‑sensitive(上下文相关)Linear Bounded Automaton(线性受限自动机)
2Context‑free(上下文无关)Pushdown Automaton(下推自动机)
3Regular(正规)Finite Automaton(有限自动机)
  • SQL、JavaScript、HTML → 类型 2(或更强)
  • 正则表达式 → 仅类型 3

为什么这很重要

正则表达式 无法计数或嵌套。一个经典例子:

((()))   ✅
(()())   ✅
(()      ❌

如果正则表达式无法可靠地判断括号是否平衡,那么期望它能够正确建模 复杂、嵌套的攻击负载 就是不现实的。

核心问题

你正在使用最弱的语言类别(类型 3)去检测用更强语言(类型 2 及以上)编写的攻击。

结论

  • 基于正则的WAF 速度快但脆弱:会产生绕过和误报。
  • 语义分析 评估输入的含义,显著降低误报和漏报。
  • SafeLine WAF 展示了现代语言感知方法如何在无需无休止规则调优循环的情况下保护应用。

通过从模式匹配转向意图理解,组织终于可以获得在真实环境中有效的WAF。

# SafeLine WAF: From Pattern Matching to Intent Understanding

SafeLine WAF represents a shift in defense philosophy:

-**Not** “does this string contain bad words?”
-**Yes** – “does this input form executable logic?”
-**Yes** – “what is the attacker trying to achieve?”

结果

  • 显著更难绕过
  • 大幅减少误报
  • 检测方式与真实攻击的工作方式保持一致

现代网络攻击是 程序,而不仅仅是字符串。
如果攻击者使用编程语言构建有效负载,防御者需要能够 理解这些语言 的系统,而不仅仅是匹配关键字。

这就是为什么语义分析不仅仅是一次优化——它是必需的。

Official Website:

Back to Blog

相关文章

阅读更多 »

仓库利用的权威指南

引言 仓库本质上只是一个 3‑D 盒子。利用率只是衡量你实际使用了该盒子多少的指标。虽然物流 c...