RASP技术进阶系列（一）：与WAF的“相爱相杀”

用什么来保护Web应用的安全？猜想大部分安全从业者都会回答：“WAF（Web Application Firewall, 应用程序防火墙）。”不过RASP（Runtime Application Self-Protection，应用运行时自我保护）横空出世，似乎有取而代之的意味。

长期以来，防火墙一直是大家公认的抵御外部攻击的关键措施。而WAF作为防火墙中的“偏科生”，更擅长于分析应用流量。简单而言，WAF是一种专门用于分析HTTP/HTTPS流量的专用防火墙，可以深入到每一次 HTTP/HTTPS请求和详情中去检查是否包含敏感字段，然后放行正常行为，拦截恶意行为，就像自来水过滤器一样，把“杂质”从庞大的流量中剔除出去，这样应用程序就只会响应正常的请求，从而达到保护应用程序的目的。

图1 WAF的工作位置

WAF的困境

WAF粗看起来像是一个简易且成熟的解决方案，但在实际真正使用时，可能会面临很多挑战。

1. 规则与业务场景无法对应

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

1+AND+3*2*1%3D6+AND+388%3D388

这种流量在WAF解析时可能会面临以下两种情况。

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

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

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

2. 可以被轻松绕过

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

例如Shiro RememberMe字段是使用AES加密的Base64编码，但是其AES加密密钥却是硬编码的，因此可以使用如下流程进行WAF绕过：

图2 WAF绕过示例流程

当Shiro服务器接收到恶意构造的RememberMe Cookie后，将会对其进行Base64解码、AES解密，最终将会反序列化构造好的恶意命令，最终导致被攻击。针对此类攻击，所有的通信数据都是经过加密的，WAF从流量侧无法理解这样的流量，也就无法进行有效的拦截。

3. 无法防御0day漏洞

由于自身工作机制，WAF可以在防御已知漏洞方面起到效果，但是无法防御0day漏洞。攻击者可以在厂商发布策略更新前就开始利用0day漏洞，而WAF通常在漏洞爆发的数小时后才能完成策略更新。

4. 维护成本高

WAF的维护不仅限于上述防护策略的维护，还体现在对于应用的适配上。目前很多WAF产品都提供了“虚拟补丁”功能，可以用来修复应用程序的缺陷，而不需要修改源代码。但这实际上给WAF维护人员带来了巨大的挑战，因为安全运营人员需要同时对业务逻辑和WAF配置参数具备深入了解后，才能写出精准且高效的策略。

RASP真能取代WAF吗？

就像WAF是防火墙的演进版本一样，大家喜欢把RASP称为下一代WAF。WAF主要解决了防火墙不能根据流量内容进行拦截的问题，而RASP虽然解决了WAF所不能解决的上下文关联的问题，但是它的出现其实并不是为了取代WAF。

图3 RASP工作原理示意图

从原理上来看，RASP是从应用内部对关键函数操作的数据进行分析，即使原始请求经过加密和混淆，但是它在应用内传播到最终的底层函数时将会以明文方式被RASP截获，因此相比WAF能减少大量的误报和漏报问题。基于此特性，RASP还能为安全人员和开发人员提供更为详尽的攻击链路，包括攻击原始 Payload、代码调用堆栈等信息，方便他们进行漏洞定位、复现以及修复。

虽然RASP较为友好地解决了WAF的不足之处，可以截获真正具有风险的操作，但是它由于构建在应用程序内部，并且只对风险操作进行拦截，这样相对 WAF缺失了从宏观上对流量的监控，对于例如CC攻击、爬虫、恶意扫描等攻击行为缺少有效的防御手段。另外，RASP由于和运行时环境耦合，在实际应用时，会更关注性能和兼容性影响：

1. 性能影响：RASP工作在应用运行时环境，不可避免会占用应用的计算资源。例如对于XSS（跨站脚本攻击）类攻击，需要在用户请求和服务器响应中分析有无恶意脚本，目前业界采用的办法是使用正则表达式进行匹配。然而在一些使用庞大表单的应用中，XSS的正则匹配将会消耗大量的资源。对于这种情况，可以根据业务场景，控制匹配精度（正则匹配范围）来调整检测精度和检测速度。

2. 兼容性：RASP虽然可以关联应用程序上下文，但是对于业务的真实应用场景的理解仍然不能做到精准。例如对于一些有运维属性的应用，需要管理员从Web直接编辑命令进行执行，但是探针并不能理解类似这样的业务场景，导致命令执行被拦截。对于此类情况，可以通过配置白名单等方式来解决。另外一点，由于 RASP 探针需要工作在应用运行时环境，这就对探针的语言支持和框架支持提出了较高要求。悬镜通过“单探针”策略，在探针兼容性层面已经得到金融电商、泛互联网、车联网、电信运营商、能源电力等行业的广泛验证。

合则两利，分则两败

当单独使用WAF或者RASP的时候，它们都因为自身的短板，在一些问题上显得力不从心。但当两者结合时，它们都将在自己擅长的领域大放异彩。

1. WAF的优势

（1）攻击前流量预警：攻击者在实施真正的攻击前，会产生大量的异常流量，这些流量包括推测服务器环境信息、可注入点尝试等。这些流量通常不会直接造成危害，因此RASP可能无法获悉全量的攻击流量（只会处理可能有危害的流量），而WAF可以完整记录异常流量。

（2）对于CC攻击、爬虫、恶意扫描和脚本小子（script kiddie）这些大流量的攻击或者有明显攻击特征的流量，如果让其直接打到装有RASP插桩的应用上，会造成不必要的性能占用；另外由于RASP会占用应用程序的计算资源，因此也不适合进行过于复杂的计算。所以对于此类攻击，最好的办法就是使用WAF从流量侧对其分析和拦截。

2. RASP的优势

（1）拦截混淆和加密的流量：如前文所述，RASP并不需要对流量进行解密，可以根据场景对恶意行为进行分析，有效拦截被精心设计的攻击流量。

（2）针对业务场景进行优化：基于RASP函数Hook的特性，不仅可以对通用类、框架类的函数进行插桩，也可以对自研代码部分进行插桩。例如对于应用在交付前来不及修补的漏洞，可以通过函数级别的虚拟补丁提供防护，保证应用按时交付。

（3）极低的维护成本：除了根据需要配置虚拟补丁外，由于RASP从底层函数进行保护，所以基本上不需要对RASP的规则做任何调整即可实现应用的安全内建。

（4）兼顾东西向流量安全：RASP工作在应用程序内部，不仅可以分析南北向流量的风险，也可以分析企业内部，应用之间东西向流量的风险。例如微服务架构中涉及多个模块间的调用，它们之间通常会使用rpc等非http协议来进行数据交换，传统的 WAF 通常对其无能为力。而 RASP 则可以很好的解决这样的问题。

（5）防御0day漏洞：RASP可以保护应用运行时环境中的所有代码，包括自研代码、第三方组件、Web应用容器（Tomcat、Django、Flask等）。例如最近几个波及范围较广的0day漏洞：Log4j2 RCE（CVE-2021-44228）、Spring4Shell（CVE-2022-22965）、Fastjson反序列化漏洞（https://github.com/alibaba/fastjson/wiki/security_update_20220523），虽然攻击方式有变化，但是最终实施攻击总是需要调用一些底层的方法/函数。无论攻击入口如何变化、攻击手段如何隐蔽，都无法绕开最终关键函数的执行过程，因此RASP一定能对其进行有效拦截。

3. RASP + WAF

图4 WAF与RASP组成纵深防御体系

（1）WAF提供真实的攻击来源：企业的应用通常都是在网关或者反向代理之后的，当流量进入应用时，RASP探针在大多数情况下其实只能拿到反向代理或者网关的IP地址，这对于分析攻击来源非常不利。可以借助WAF对所有进入的流量添加Headers（例如 X-Forwarded-For），标记真实来源IP，方便对RASP拦截的攻击事件进行溯源。

（2）通过RASP拦截信息生成WAF黑名单：攻击者如果能绕过WAF进行攻击，将会给应用带来负担。通过自动化流程将RASP拦截的攻击者来源IP生成WAF IP黑名单，将会大大减慢攻击者的攻击进程，给安全人员争取应急响应的时间。

（3）根据RASP拦截信息生成WAF策略：例如RASP将异常的SQL执行上报后，安全人员可以通过分析得出那些敏感参数，并在WAF中进行标记，这既可以大大降低RASP给应用带来的性能消耗，同时也能让WAF警报更加准确。

（4）WAF与RASP联动，可以扩大应用安全防护范围：近期攻防演练活动中，红方越来越喜欢使用 0day、内存马这样的手段进行攻击，RASP可以有效进行防御。

图5 WAF+RASP部署架构示意图

总结

RASP和WAF最大的区别是：WAF的目的是发现可疑的流量，RASP则是发现具有威胁的行为。由于近期几次大的0day漏洞事件，RASP因其特点，在防护未知攻击方面，发挥了重要的作用。但是RASP并不是要取代WAF，两者是完全不同的技术，各有各的优势，也各有各的不足。WAF作为恪尽职守的哨兵，监视来自外部的可疑入侵；RASP则作为应用的贴身保镖，防御来自内部和外部的致命攻击。

关于悬镜安全

悬镜安全，DevSecOps敏捷安全领导者。起源于北京大学网络安全技术研究团队“XMIRROR”，创始人子芽。悬镜专注于以代码疫苗技术为内核，通过原创专利级"全流程软件供应链安全赋能平台+敏捷安全工具链”的第三代DevSecOps智适应威胁管理体系，持续帮助金融、车联网、泛互联网、能源等行业用户构筑起适应自身业务弹性发展、面向敏捷业务交付并引领未来架构演进的内生积极防御体系。更多信息请访问悬镜安全官网：www.xmirror.cn

RASP技术进阶系列（一）：与WAF的“相爱相杀”相关推荐

RASP技术进阶系列（三）：重大漏洞自动化热修复
在上篇文章<RASP技术进阶系列(二):东西向Web流量智能检测防御>中提到,在企业日常安全运营以及HW场景下,应用漏洞攻击应急响应和恶意流量溯源分析是安全团队的重点工作.在恶意流量溯源方 ...
阿里云CDN技术掌舵人文景：相爱相杀一路狂奔的这十年
提到阿里云CDN,不得不提技术掌舵人姚伟斌(文景),虽然他不是团队中最"老"的同学,但他却历经了淘宝业务发展最为飞速的几年,见证了从最初服务淘宝和集团内部的CDN,到如今国内服务客 ...
IAST技术进阶系列（五）：共生进化，自适应云原生
伴随着云计算带来的基础设施变革以及应用技术架构的转变,云原生和云原生应用已经成为耳熟能详的词汇.Gartner预测,到2025年,云原生平台将成为95%以上新数字化计划的基础.伴随云原生场景的普及,云 ...
IAST技术进阶系列（三）：高并发高可用场景支持
DevOps敏捷开发模式已被业界普遍认可并被广泛应用,同时伴随云原生技术的兴起,青睐采用容器编排解决方案来构建和管理应用的企业不胜枚举.但是,应用程序安全测试依赖运行时探针,采用容器编排方案同时也意味 ...
技术人如何与产品经理相爱相杀
"这是产品经理要考虑的,我只管写好代码就好了",我曾有过这种想法.产品经理就要把所有产品逻辑考虑清楚,然后交付PRD给开发人员进行研发,瀑布or迭代研发一个个里程碑.不过想法总是美 ...
云原生安全之RASP技术（应用运行时自我保护）
文章目录一.背景 1. WAF和RASP 2. waf和rasp是非此即彼的吗? 二.RASP技术(应用运行时自我保护) 1. 应用安全测试SAST.IAST.DAST 和 RASP区别 SAST, ...
DotNet进阶系列
一. 回顾历史回顾个人发展历程,自2012年初次接触开发至今(2018年)已经有六个年头,这期间陆陆续续学习并掌握了不少技术,C#语言.ORM框架.多线程技术.设计模式.前端技术.MVC.MVVM框 ...
malloc开辟的空间在哪一个区间_C++进阶系列之STL（2）SGI版本空间配置器
1.STL中的空间配置器在STL中,空间配置器分了2组,分别为一级空间配置器和二级空间配置器,但是它们都有自己各自运用的场合:一般说来,一级空间配置器一般分配的空间大于128B,二级空间配置器的分配空 ...
超全PHP学习资源整理：入门到进阶系列
PHP是少数几门在语言层面饱受诟病,但在实际开发和应用上却又让人无法撒手的语言之一.就好比路边摊小吃,一遍骂人家不卫生,一遍却又说:真香.所谓接地气,不外如此,大道理不说,PHP光是轮子多.市场占有率 ...

RASP技术进阶系列（一）：与WAF的“相爱相杀”

RASP技术进阶系列（一）：与WAF的“相爱相杀”相关推荐

最新文章

热门文章