第三章：WAF检测机制分析
大家好，我是老周。今天咱们聊聊WAF到底是怎么发现SQL注入的。说实话，很多人觉得WAF很神秘，其实拆开来看，无非就是那几招。我在项目里见过太多人一遇到WAF就慌了，其实你只要摸清它的底牌，绕过就变得有章可循。
3.1 基于签名的检测——最古老也最直接
签名检测，说白了就是“黑名单”思路。WAF维护一个特征库，里面存着各种已知的攻击payload。比如你传了个 1' OR '1'='1，WAF一看，嗯，这个字符串我认识，直接拦下。
我早年做渗透测试时，遇到过一家银行的WAF，它的签名库特别老。我试了试 UNION SELECT 被拦了，但改成 UNION/**/SELECT 就过去了。为什么？因为它的签名只匹配了空格分隔的写法。
签名检测的特点：
- 速度快，几乎不消耗计算资源
- 误报率低，但漏报率高
- 对变种攻击基本无效
你想想看，签名检测就像小区门口的保安，只认黑名单上的人。换个马甲，换个发型，他就认不出来了。
3.2 基于正则的检测——更灵活但更费劲
正则检测比签名高级一点。它不匹配具体字符串，而是匹配模式。比如检测 (\bunion\b.*\bselect\b) 这种模式，不管你怎么加注释、换大小写，只要出现了union和select的组合，就触发告警。
我记得有一次，客户的内网系统被注入了，但WAF日志里什么都没记录。后来我一看，原来WAF的正则写得太死了，只匹配了 union select 中间带一个空格的情况。攻击者用了 union%0aselect，换行符绕过了。
小技巧：正则检测虽然灵活，但写正则的人往往考虑不周全。你可以试试用注释、换行、特殊编码来绕过。我习惯先扔一个简单的payload，看看WAF的反应，再逐步调整。
正则检测的弱点在于：它只能匹配已知的模式。你换个思路，比如用 UNION DISTINCT SELECT，很多正则就傻眼了。
3.3 基于行为分析的检测——看你的“动作”
行为分析不看你传了什么，而是看你“怎么传”。比如一个普通用户，正常登录时只会传用户名和密码。但攻击者可能会在短时间内发送大量带特殊字符的请求，或者请求的URL参数突然变长了很多。
我在一个电商项目中遇到过这种情况。WAF的行为分析模块发现，某个IP在3秒内发了50个请求，而且每个请求的 id 参数都带单引号。系统直接把这个IP拉黑了。嗯，这里要注意，行为分析对慢速注入效果很差。你一天只发一个请求，它根本发现不了。
避坑指南：我曾经在测试一个政府网站时，用了代理池轮换IP，以为能绕过行为分析。结果WAF检测的是会话级别的行为，不是IP级别的。我换了IP但session没变，照样被拦。后来我每次请求都新建session，才搞定。
3.4 基于机器学习的检测——新时代的“黑科技”
机器学习检测，说白了就是让WAF自己学什么是正常流量，什么是异常流量。它不需要你写规则，只需要喂数据。比如你给WAF看100万条正常请求，再给它看1万条攻击请求，它自己就能总结出规律。
我去年帮一家金融公司做安全评估，他们的WAF就是基于ML的。我试了各种绕过技巧，什么大小写、注释、编码，全被拦了。后来我发现，它的模型对 sleep(5) 这种时间盲注特别敏感，但对 benchmark(10000000,md5(1)) 这种就识别不了。为什么？因为训练数据里没有这种样本。
ML检测的局限性：
- 依赖训练数据的质量，数据不全就漏报
- 对零日攻击（没见过的新攻击）基本无效
- 计算资源消耗大，可能影响正常业务
你想想看，ML模型就像一个学生，你教过它的它都会，没教过的它就不会。所以对付ML WAF，最好的办法就是用一些冷门的、不常见的注入手法。
3.5 四种检测机制的对比
为了方便你理解，我整理了一个表格。这四种机制在实际WAF中往往是组合使用的，很少有WAF只用一种。
| 检测机制 | 检测原理 | 优点 | 缺点 | 绕过思路 |
|---|---|---|---|---|
| 签名检测 | 匹配已知攻击字符串 | 速度快、误报低 | 漏报高、无法应对变种 | 变形、编码、注释 |
| 正则检测 | 匹配攻击模式 | 比签名灵活 | 正则写不好就漏 | 换思路、用冷门语法 |
| 行为分析 | 检测请求频率、参数变化 | 能发现未知攻击 | 对慢速攻击无效 | 慢速、分布式 |
| 机器学习 | 基于历史数据建模 | 自适应、能发现变种 | 依赖训练数据、资源消耗大 | 用冷门手法、对抗样本 |
3.6 核心逻辑框架图
下面这张图展示了WAF检测SQL注入的完整流程。从请求进入，到层层过滤，最后决定放行还是拦截。我画这张图时，特意把四种机制的关系理清楚了。
从这张图你可以看到，WAF的检测是层层递进的。签名和正则属于“静态检测”，行为分析属于“动态检测”。至于机器学习，它其实可以嵌入到任何一层，也可以单独作为一个模块。我个人的习惯是，先摸清WAF用了哪几层，再针对性地设计绕过方案。
实战建议：测试WAF时，不要一上来就用复杂payload。先发一个简单的 '，看看WAF的反应。如果被拦了，说明签名层或正则层生效了。如果没被拦，再逐步增加复杂度。这样你就能摸清WAF的检测深度。
好了，关于WAF的检测机制，今天就聊到这里。记住一句话：WAF再强，也是人写的。只要是人写的，就有漏洞。下一章我会带你实战，看看怎么用SQLMap绕过这些检测机制。