1. WAF基础认知：什么是WAF、WAF的工作原理、常见WAF产品介绍

大家好，我是老周。做安全测试这么多年，我见过太多人一上来就拿着SQLMap对着目标猛怼，结果被WAF拦得死死的，连个错误页面都看不到。说实话，这就像你拿着万能钥匙去开锁，结果发现门是防弹玻璃做的——你连门都摸不到。

所以，咱们得先搞清楚WAF到底是什么。别急，这一章我会把WAF的底裤都扒干净。

1.1 什么是WAF？

WAF，全称Web Application Firewall，中文叫Web应用防火墙。说白了，它就是站在你和目标网站之间的一道安检门。你发的每个请求，都得先过它这一关。

我打个比方：你想想看，你去机场坐飞机，过安检时工作人员会检查你的行李。WAF干的就是这个活——它检查你发给Web服务器的每个HTTP请求，看看里面有没有夹带“私货”。比如SQL注入语句、XSS攻击脚本、文件包含路径等等。

我个人习惯把WAF分成两类：

• 云WAF：部署在云端，通过DNS解析把流量引过去。Cloudflare、AWS WAF、阿里云WAF都属于这类。
• 本地WAF：部署在你自己服务器上，或者作为反向代理。ModSecurity就是最典型的代表。

嗯，这里要注意：云WAF你基本碰不到它的物理设备，而本地WAF你有可能直接跟它打交道。这个区别在后面的绕过技巧里会体现出来。

1.2 WAF的工作原理

WAF怎么工作的？其实核心就三步：

1. 解析请求：把HTTP请求拆开，看URL、Header、Body、Cookie这些部分。
2. 匹配规则：用正则表达式或者签名库去匹配这些部分，看有没有恶意特征。
3. 执行动作：匹配到了就拦截、记录日志、或者返回一个假页面。

听起来简单对吧？但这里有个坑——WAF的解析能力和Web服务器的解析能力可能不一样。我在项目中遇到过好几次，WAF认为某个参数是安全的，但到了后端服务器却被解析成了恶意代码。这就是绕过WAF的核心思路之一。

我画了一张图，帮你理解WAF在整个请求链路中的位置：

从这张图你能看到，WAF卡在攻击者和Web服务器之间。它要么放行请求，要么拦截请求。但问题是——它怎么判断一个请求是不是恶意的？

1.3 WAF的检测方式

WAF的检测方式主要有三种，我一个个说：

检测方式	原理	优缺点
正则匹配	用正则表达式匹配请求中的关键字，比如 union、select、1=1	速度快，但容易被绕过。比如大小写、注释符、编码等
语义分析	解析SQL语句的语法结构，判断是否合法	准确率高，但性能开销大。ModSecurity的libinjection就用这个
机器学习	训练模型识别恶意流量	能发现未知攻击，但误报率高，且需要大量样本

我记得有一次，一个客户说他们的WAF怎么都拦不住某个SQL注入。我过去一看，发现他们只开了正则匹配，而且规则写得特别粗糙。攻击者用了个简单的注释符 /**/ 就把规则绕过去了。嗯，这就是典型的“规则不全”问题。

1.4 常见WAF产品介绍

市面上WAF产品很多，但咱们做渗透测试的，最常碰到的就这几个：

1.4.1 ModSecurity

ModSecurity是开源WAF里的老大哥。它本身是一个模块，可以集成到Nginx、Apache、IIS里。它的核心是OWASP Core Rule Set（CRS），一套非常全面的规则库。

我个人很喜欢ModSecurity，因为它完全透明。你能看到它怎么解析请求、怎么匹配规则、怎么拦截。这对于学习WAF绕过来说，简直是教科书级别的素材。

举个例子，ModSecurity的规则长这样：

SecRule REQUEST_URI "@contains select" \
  "id:1000, \
   phase:1, \
   deny, \
   msg:'SQL Injection - SELECT detected'"

这条规则的意思是：如果请求URI里包含“select”这个词，就拦截。你看，多简单粗暴。但绕过它也很简单——用URL编码或者大小写就行了。

1.4.2 Cloudflare WAF

Cloudflare的WAF是云WAF的代表。它通过DNS解析把流量引到自己的边缘节点，在那里做检测。它的优势是分布广、延迟低、能抗DDoS。

但Cloudflare有个特点——它对已知攻击的检测非常准，但对变种攻击的检测能力一般。我在项目中遇到过，同样的SQL注入payload，换个编码方式就能绕过Cloudflare的检测。

Cloudflare的规则分几个等级：

• Off：不检测
• Low：只检测最明显的攻击
• Medium：默认等级，检测常见攻击
• High：严格检测，但误报率高

你想想看，如果目标用的是Low等级，那绕过就太容易了。但如果是High等级，你就得花点心思了。

1.4.3 AWS WAF

AWS WAF是亚马逊云的安全产品。它跟Cloudflare类似，也是云WAF。但它有个特点——它跟AWS的其他服务集成得很好，比如ALB、CloudFront、API Gateway。

AWS WAF的规则是用JSON写的，你可以自定义。比如：

{
  "Name": "SQLInjectionRule",
  "Priority": 1,
  "Action": { "Block": {} },
  "VisibilityConfig": { ... },
  "Statement": {
    "SqliMatchStatement": {
      "FieldToMatch": { "Body": {} },
      "TextTransformations": [
        { "Priority": 0, "Type": "URL_DECODE" }
      ]
    }
  }
}

这段规则的意思是：对请求体做SQL注入检测，并且先做一次URL解码。你看，AWS WAF已经考虑到了编码绕过的问题。但道高一尺魔高一丈，我们后面会讲怎么对付它。

1.4.4 其他常见WAF

除了上面三个，还有几个你可能会碰到：

• 阿里云WAF：国内用的多，规则库偏向中文场景
• 腾讯云WAF：跟阿里云类似，但有些规则不一样
• F5 BIG-IP ASM：企业级硬件WAF，性能强但贵
• Imperva：老牌WAF，很多金融行业在用

我曾经在测试一个金融客户时，碰到的是Imperva WAF。那家伙规则特别严，连正常的 SELECT 语句都拦。后来我发现，它把 SELECT 当成关键字了，但 SeLeCt 这种大小写混合的它反而放行了。你看，这就是WAF的漏洞。

1.5 总结一下

这一章我们讲了WAF的基础认知。说白了，WAF就是一道安检门，它用规则去匹配恶意请求。但规则总有漏洞，解析总有偏差，这就是我们绕过WAF的切入点。

我个人建议，你在开始任何注入测试之前，先花10分钟搞清楚目标用的是什么WAF。怎么搞？发几个测试请求，看响应头、看错误页面、看拦截提示。这些信息会告诉你WAF的类型和版本。

嗯，这一章就到这里。记住一句话：知己知彼，百战不殆。了解WAF，是绕过WAF的第一步。

---