RASP由来

RASP（Runtime application self-protection）运行时应用自我保护。Gartner 在2014年应用安全报告里将 RASP 列为应用安全领域的关键趋势，并将其定义为:

Applications should not be delegating most of their runtime protection to the external devices. Applications should be capable of self-protection (i.e., have protection features built into the application runtime environment).

RASP VS WAF

传统的WAF的安全防护已经逐渐的不能够完全的保护我们的系统

传统的WAF主要是通过获取请求流量，对流量进行分析、筛选和过滤等等操作，进而能够通过不同种类的攻击流量特征来进行拦截请求，但是好的WAF需要一个好的规则库，在各式各样的漏洞层出不穷的今天，似乎这中被动性的安全防护显得有一点鸡肋

而对于新兴的RASP技术，这种主动式的防御手段，能够和应用同时运行，进行捆绑式运用，根据请求的上下文，对可能的攻击进行更加精准的识别，并且，对于RASP技术，只要能够将恶意的sink点完整的覆盖甚至能够防御未知的漏洞攻击，大大减轻了WAF的规则库的维护

与传统的 WAF(Web Ap-plication Firewall)技术相比, RASP 技术准确性更高, 更可靠。WAF 是基于模式匹配并仅对所有输入流量进行检测,而 RASP 是在发生攻击的关键节点处同时关注输入和输出, 能够根据数据流分析输入在应用程序内部的行为, 从而精准拦截攻击。RASP技术已在 Web 安全及漏洞检测领域被广泛应用, 例如在Web 安全检测、脚本注入安全、Web 框架漏洞检测、智能合约漏洞防护等方面得到了有效解决方案

WAF技术也有着很一定的弊端

1. 规则库难以维护

   WAF实际上是以一种简单粗暴的方式来保护应用的。WAF在分析流量时，只会针对一条流量进行分析，不会关联上下文

   可能造成一种虽然看起来像是 SQL注入的形式，但是背后的逻辑可能和SQL处理没有关系，比如在SPEL等表达式中，也可能会有类似的写法。如果严格按照该逻辑去分析流量，就有可能造成误报。

   另外一种情况是，如果处理这条请求背后的应用确实进行了SQL操作，但是已经使用了预编译等方式对传入数据进行了清洗，那么这个请求实际上并不会对业务本身造成危害，所以也会产生误报。

   因此，在设置WAF规则的时候，如果过于严格，就会造成误报；过于宽松，又会导致真正具有风险的流量被放过。这便需要专家针对企业的业务场景进行调整，这个工作并不是一劳永逸，随着时间的推移、应用的更迭，WAF策略也需要不断调整。

2. 能够使用trick进行Bypass

   绕过WAF防御的主要方式是对流量进行加密和混淆。WAF在解密流量时，由于无法深入到应用内部，因此只能对HTTPS流量进行解密，再深一层就无能为力了，比如将数据通过Base64加密，甚至只需简单切换字母的大小写就可以绕过WAF的防御。

   甚至可以使用更加复杂的语法，使得WAF的功能失效，达到暴力绕过的目的

3. 无法预先检测漏洞

   在新型漏洞披露之前，在最新的WAF规则下，新型漏洞的请求流量仍是无害的流量，将不会进行拦截，在每天全球都有各种的漏洞产生的今天，成了他最大的软肋

而对于RASP的优点

1. 拦截混淆和加密的流量， 获取的直接是在应用场景的功能

2. 能够进行各种优化，可以在危险函数进行Hook, 获取是一些无害的函数进行Hook

3. 能够提前防御漏洞，即时存在未知的漏洞能够利用，但是究其根本都是调用了一些已知的方法进行恶意操作，RASP使用插桩技术监测危险函数

但是有利有弊，是一把双刃剑

结合两者才是更好的选择

WAF结合RASP联动组成防御体系，一内一外，WAF对外防护DDOS / CC / 已知漏洞，RASP对内防护0Day漏洞，WAF的漏网之鱼

RASP的必要性

当前，多数应用都依赖于像入侵防护系统（IPS）和 Web 应用防火墙（WAF）等外部防护。WAF部署在Web应用前线，通过对HTTP/HTTPS的有目的性的策略来达到对Web应用的保护，在HTTP流量到达应用服务器之前对其进行分析，但是基于流量的检测分析手段容易被绕过。相比于传统基于边界的防护产品，RASP不需要依赖规则

同样，研究表明, 将近一半的攻击者在发现 Web 应用上传漏洞后会上传一个 Webshell。攻击者上传的Webshell 与网站管理员远程管理所使用的功能类似,通过 HTTP 请求接收命令并提供响应, 可穿越防火墙, 难以检测。Webshell 最初包含的功能强大, 但是文件较大、服务器端代码较多; 针对网站对文件大小上传的限制, 逐渐演变为代码量小、只有单一上传文件功能的小文件; 为了更加隐蔽, Webshell 配合管理工具, 只需简单的脚本执行语句即可; 为了更好的躲避检测, Webshell 还采用了加密、混淆等手段。但是随着近年来攻防双方的博弈, Webshell 获得了越来越多的关注, 其检测方法也更加健全, 包括文本特征检测、行为特征分析、流量检测、日志检测、统计学检测等方法, 并结合机器学习、深度学习等算法提高了检测的准确率, 以及 XDR(Extended Detectionand Response, 扩展检测和响应)[2]等防御技术的提出,使得传统的以文件形式落地的 Webshell 生存空间越来越小。因此, 内存型 Webshell 应运而生

内存型 Webshell 是在内存中写入恶意后门, 不会有文件落地, 利用中间件的进程执行这些恶意代码, 达到远程并持久控制 Web 服务器的目的。早在2017 年, 内存型 Webshell 已经初露头角, 研究人员通过调试 Tomcat 代码, 在运行时动态插入 Filter 和Valve, 可以达到隐藏 shell 的效果, 只是这两种方法在 Tomcat 重启后会失效。2018 年, 研究人员利用agent 技术通过进程注入方式实现了内存型 Webshell,并 且 使 用 ShutdownHook 机 制 实 现 服 务 重 启 后Webshell 复活的功能, 进一步拓宽了内存马的使用场 景 。 2020 年 , 随 着 攻 防 演 练 的 兴 起 , 内 存 型Webshell 再次回归视野。乘着 Java 反序列化漏洞的东风, 内存型 Webshell 引发了更多的关注。2020 年,研究人员基于特定框架 Java Spring MVC 的利用, 构造了一个 Spring Controller Webshell, 利用多种技术注入到内存中, 实现无文件攻击。2021 年, 研究人员 利 用 Shiro 的 反 序 列 化 漏 洞 , 实 现 了 内 存 型Webshell 的注入及 Tomcat 通用回显。除此之外, 常用的 Webshell 管理工具, 如冰蝎、哥斯拉、蚁剑等, 都在最新版本中增加了内存型 Webshell 注入的功能。内存型 Webshell 已经成为了攻击方的必备工具, 针对内存型 Webshell 的检测和防护也越来越受重视

我们完全可以使用RASP监测技术进行查杀

针对内存型 Webshell, RASP 主要监测两类函数, 一类是与输入源中的组件相关的注册组件类函数, 另一类是为达到特权状态所请求的函数,称为特权类函数

而同样的，在这几次重大的0day披露中，RASP的重用也逐渐凸显

2021年12月，Apache Log4j 开源组件在业内被曝出严重漏洞

2022年4月，Spring 开源应用开发框架也被爆出了一个严重高危漏洞

引用

面向 Java 的高对抗内存型 Webshell 检测技术

https://paper.seebug.org/330/

https://cg.xmirror.cn/