RASP - Runtime Application Self Protection

RASP 意思是应用运行时自我保护，算是相对"比较"新的安全技术了。顾名思义嘛，RASP 就是在应用运行时检测"并阻止"应用级别的攻击，可以类比成集成在应用程序上的 IPS/IDS。RASP 防御的核心就是在 Web App 执行关键代码前做检测和防御逻辑。

那说到 RASP 就不得不提 WAF，有些乙方会说" RASP 是颠覆WAF的存在，RASP 是下一代 WAF"，这个肯定是推销的话术咯~不过 RASP 倒确实能和 WAF 互为补充，作为纵深防御中的两个环节。

WAF VS RASP

WAF 其实就是个专注于HTTP(S)协议的防火墙，根据写好的安全规则检查入站流量。这里的安全规则是 WAF 的核心，入站流量命中了安全规则，WAF可能会做出一些自动化响应，但是我们知道，安全规则是有滞后性的，这就像一定是先有病毒才有杀毒软件，安全规则必然是一直追着"敌人"跑；同时，WAF 的误报率一直是居高不下，这对于安全运营来说也是很大的压力。

接下来需要举例子来说明 RASP 的优势：

• 我们都知道 WAF 是有被绕过的概率的，无论是编码、注释、通配符混淆和宽字节等等，运用这些技术有机会绕过写好的 SQL 防注入 WAF 规则；而 RASP 技术可以做到：对Web App 拼接的 SQL 到数据库执行之前进行拦截或检测。这意味着无论攻击者使用什么方式渗透到了应用程序执行 SQL 阶段，这个 SQL 总要执行的，那在执行之前做检测是最短路径，也是最有效的方式之一。

接下来再举一个例子：

• 你项目中用到了 Struts 框架，假设一个 Struts 的 0day 出来了，由于 WAF IDS 这些层并没有提前写相关规则（0day也没法写啊），攻击者可以轻易绕过他们，这时候假设你们落地了 RASP，RASP 观察到的现象就是，自己运行了一段 OGNL 代码，然后莫名其妙地产生了未预期的代码执行，比如运行系统命令...这时候 RASP 就一定有告警，而且告警基本不存在误报。

上面的两个例子都能很好的展示 RASP 的优势，它作为应用程序内部的保护机制，不依赖于外部的规则库来判断恶意攻击行为，而是通过实时检测应用程序的行为和上下文来判断是否有高危行为。更进一步来说，RASP 这种内在集成方式更准确、更主动。

虽然 WAF 在防御已知攻击方面仍有很不错的效果，而 RASP 提供了一种更深入、更细致的安全防护措施，特别是在对抗那些复杂或尚未被广泛识别的安全问题时效果更显著。因此，WAF + RASP 才是比较好的纵深。

RASP 的优势

首先，RASP 基本不存在误报：

无论是入侵检测系统还是防火墙，这类处于安全边界的防御手段都是基于请求特征检测攻击，因此对于外部使用 Zap、Sqlmap之类工具产生的扫描，处于边界的防御手段都会产生大量的告警。但 RASP 不同以上，可以认为它运行在应用的内部，这意味着入侵者操作失败就一定不会触发检测逻辑，因此每一条告警都是准确的（这里不能钻牛角尖，你要说研发写代码的时候乱搞触发了 RASP 的告警怎么办？确实存在这种情况）。

安全边界处会产生大量安全警报，例如有人扫描你的/git、/.ssh、/.env等等，这些扫描都是攻击者使用自动化工具产生的，但你要知道，攻击者几乎都是大批量无脑扫描的，扫描不到漏洞攻击者压根就不会对你的系统有下一步动作了。由于 WAF 本身不知道你 Web 应用内部信息，它没办法判断这次扫描的危害性有多大，因此为了保险起见他选择告警给你看。例如你的技术栈压根不涉及 WordPress 或 PHP，但扫描的人会扫这里的漏洞，WAF 检测到了就一定会告警...

其次，RASP 能通过上下文更好的追踪入侵者的行为：

简单来说，假设入侵者绕过了 WAF，拼接了 SQL 并要求应用程序执行，在执行阶段 RASP 是能看到完整 SQL 的，通过 SQL 向上关联很容易能找到 WAF 究竟是哪里漏过了这条 SQL。

最后，RASP 可以对抗很多"未知"漏洞：

对于未知的漏洞，网络安全边界的防御手段不一定能识别到，例如某天 log4j 又爆出来了新的漏洞，入侵者无视你的外部防御手段直达 Web App，此时你的 RASP 使用调用栈检测方式发现，JNDI 触发了系统命令调用，这时候系统就会产生告警或者直接抛异常阻止执行。

RASP 为什么会产生这次告警或者阻止这次行为？因为它发现应用做了正常情况下不应该做的事情。什么是正常情况下不应该做的事情？比如命令执行、文件读取、文件上传、SSRF 等都是。

这里的关键在于，WAF 看到的流量特征几乎是无穷无尽的，但是应用的行为类型是可以穷举的。从应用行为异常的角度去检测，范围可以大幅收敛到有限的类型，这也是 RASP 可以无视流量特征并且不依赖规则更新就可以防御几乎全部 0day 的根本原因。无论外部来的流量特征怎么变，漏洞利用的本质都是让应用来做一些不安全的动作。

劣势呢？

第一点就是可能会拖慢服务器性能，服务器性能就是钱呀，假设 RASP 要占一台服务器的 20% CPU，这成本就是无法接受的；但是如果只占 3% 那就属于可接受范围；虽然很多产品宣称自己对系统性能的影响低于3% 5%，但在实际落地的过程中，还是会出现很多因为系统、应用差异，而导致性能恶化的情况。

第二点是泄露敏感信息，可以以日志打印太多暴露敏感信息为类比；

第三点是复杂度或者说上线成本可能有点高，无论你用开源的、商业化或者自研方案，都面临长期大量的稳定性测试，而当你后端技术栈太复杂时，又是go又是java又是rust的，要针对每一个技术栈都做 RASP，这样复杂度就又上一个台阶。

以上三点只能说是技术上的难点，但想要做 RASP 有一个超级大坑：

推广难度

为什么？要知道，安全部门做个 WAF、做个入侵检测或者做个终端安全策略，最多也就需要运维部门帮忙。以上内容实际上并不需要研发参与，或者说不需要研发有太多的工作量；而 RASP 不同，RASP 和应用是强关联的，RASP 的推广实际上是安全意识的推广，所以难度系数真的很高。

落地

小公司大概率玩不转，具体实现思路就是通过 JavaAgent 的形式将 RASP 运行在 JVM 上，然后借助 Instrumentation 来 Hook 关键的类和方法。不过我的建议是，如果非要自研可以以 BTrace 为底来做基础的检测，别做 Protection，先做 Detection，小步快跑迭代，这里面最头疼的还是热更新。如果不执著追求自研，开源的方案还是蛮多的，百度的OpenRASP、jrasp、AppSensor等有很多。如果还是嫌麻烦，直接去买商业化方案就行咯。

多说一句，RASP 这概念倒是提出的蛮早，大概十几年前就在说，不过实际落地案例还不够多，大家都是边做试验边落地的初期阶段...

绕过

有了 RASP 就能高枕无忧了吗？很遗憾，并不能...大佬们师傅们还是能绕过的，但难度上升了一个量级。