前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >与WAF的“相爱相杀”的RASP

与WAF的“相爱相杀”的RASP

原创
作者头像
德迅云安全--陈琦琦
发布2024-05-24 20:34:04
800
发布2024-05-24 20:34:04

用什么来保护Web应用的安全?

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

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

WAF的困境

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

规则与业务场景无法对应

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

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

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

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

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

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

可以被轻松绕过

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

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

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

无法防御0day漏洞

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

维护成本高

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

RASP真能取代WAF吗?

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

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

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

性能影响

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

兼容性

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

合则两利,分则两败

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

WAF的优势

  1. 攻击前流量预警:攻击者在实施真正的攻击前,会产生大量的异常流量,这些流量包括推测服务器环境信息、可注入点尝试等。这些流量通常不会直接造成危害,因此RASP可能无法获悉全量的攻击流量(只会处理可能有危害的流量),而WAF可以完整记录异常流量。
  2. 对于CC攻击、爬虫、恶意扫描和脚本小子(script kiddie)这些大流量的攻击或者有明显攻击特征的流量,如果让其直接打到装有RASP插桩的应用上,会造成不必要的性能占用;另外由于RASP会占用应用程序的计算资源,因此也不适合进行过于复杂的计算。所以对于此类攻击,最好的办法就是使用WAF从流量侧对其分析和拦截。

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反序列化漏洞,虽然攻击方式有变化,但是最终实施攻击总是需要调用一些底层的方法/函数。无论攻击入口如何变化、攻击手段如何隐蔽,都无法绕开最终关键函数的执行过程,因此RASP一定能对其进行有效拦截。

RASP + WAF

  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可以有效进行防御。

德迅蜂巢

  1. 定义:

自主研发,能够很好集成到云原生复杂多变的环境中,如PaaS云平台、OpenShift、Kubernetes、Jenkins、Harbor、JFrog等等。通过提供覆盖容器全生命周期的一站式容器安全解决方案,德迅蜂巢可实现容器安全预测、防御、检测和响应的安全闭环。

  1. 核心理念:

在开发阶段(Dev),遵循“安全左移”原则,做到上线即安全

在运行阶段(Ops),遵循“持续监控&响应”原则,做到完全自适应

  1. 功能:
  2. 资产清点:德迅蜂巢可以清晰地盘点工作负载本身的相关信息,此外,还能够实现不同工作负载之间的关系可视化,帮助运维和安全人员梳理业务及其复杂的关系,弥补安全与业务的鸿沟。
  3. 镜像扫描:德迅蜂巢的镜像检查能力已经覆盖到开发、测试等多个环节中,可快速发现镜像中存在的漏洞、病毒木马、Webshell等镜像风险。
  4. 微隔离:德迅蜂巢微隔离原生自适应容器多变的环境。通过对访问关系的梳理和学习,提供自适应、自迁移、自维护的网络隔离策略,帮助用户快速、安全地落地容器微隔离能力。
  5. 入侵检测:德迅蜂巢通过多锚点入侵监测分析,实时监测容器中的已知威胁、恶意行为、异常事件,监测到入侵事件后,对失陷容器快速安全响应,把损失降到最低。
  6. 合规基线:德迅蜂巢构建基于CIS Benchmark的最佳安全操作实践检查,帮助企业实施和完善容器合规规范,可实现一键自动化检测,并提供可视化基线检查结果和代码级修复建议。
  7. 核心架构

总结

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

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 用什么来保护Web应用的安全?
  • WAF的困境
    • 规则与业务场景无法对应
      • 可以被轻松绕过
        • 无法防御0day漏洞
          • 维护成本高
          • RASP真能取代WAF吗?
            • 性能影响
              • 兼容性
              • 合则两利,分则两败
                • WAF的优势
                  • RASP的优势
                    • RASP + WAF
                    • 德迅蜂巢
                    • 总结
                    相关产品与服务
                    Web 应用防火墙
                    腾讯云 Web 应用防火墙(Web Application Firewall,WAF)帮助腾讯云内及云外用户应对 Web 攻击、入侵、漏洞利用、挂马、篡改、后门、爬虫等网站及 Web 业务安全防护问题。企业通过部署腾讯云 WAF 服务,将 Web 攻击威胁压力转移到腾讯云 WAF 防护集群节点,分钟级获取腾讯 Web 业务防护能力,为网站及 Web 业务安全运营保驾护航。
                    领券
                    问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档