写在前面的话


对于安全社区来说,Web应用防火墙(WAF)似乎一直以来都是一个大家默认都要使用的东西,而且几乎也没有人会反对使用Web应用防火墙。在这篇文章中,我们将给大家提供一个新的视角去看待WAF,并会对Web应用防火墙的使用效率问题与替代性技术进行深入探讨。



Web应用程序防火墙诞生于互联网的早期时间,特别是在2002年ModSecurity项目诞生后得到了普及和广泛应用。WAF的工作原理本质上是拦截每个HTTP请求(有时也拦截响应)并使用成百上千个正则表达式评估URI、Header和Body,有的时候还会借助机器学习来进行分析和评估。如果请求中的数据包含类似SQL或Shell之类的代码,服务器可能会阻止我们的请求。


在网络安全领域的起步阶段,WAF似乎是一个好主意。当时的HTTP请求提及很小,而且请求也不频繁,并且大多包含的都是普通的表单数据。但现在,WAF似乎是一个已经“过时”的东西了,我们似乎还有更好的技术,甚至是目前最先进的WAF都可以使用其他技术来代替。


Web应用防火墙的性能问题


由于WAF会使用数百个正则表达式来对每一个请求执行安全检测,那么有人可能会问了:“这样效率不会很低吗?”没错,确实非常低。


除了对每个请求进行处理会减慢速度之外,我们还需要大量额外的RAM来缓冲请求。由于在WAF完成分析之前,缓冲区中的任何字节都无法刷新到后端服务器,因此我们可能会需要好几个GB的RAM来存储请求Body。默认情况下,像Nginx这样的服务器会缓冲请求,但是足够大的并发请求(例如推送容器映像)可能会使缓冲Web服务器耗尽RAM。当使用WAF时,每台服务器都会成为缓冲Web服务器,但这与许多类型的应用程序并不兼容。


毫无疑问,现在的计算机设备速度非常快,而且硬件价格也不贵,但我们不应该在WAF上这样去花费CPU和RAM,除非它们真的可以成为真正有效的安全工具,但事实并非如此...


WAF很容易被绕过


自WAF诞生之日起,WAF厂商就跟威胁行为者陷入了一场持久的“军备战”,但似乎一直以来威胁行为者的水平会更高一些。WAF声称要阻止各种类型的攻击以及复杂的语法,比如说SQL、Shell和其他各种编程语言,其中可能还包括各种注释、字符转义、编码问题和其他各种特殊情况。这也就意味着,从安全攻防角度来说,威胁行为者总是拥有显著的优势,如果他们足够聪明,技术足够硬,他们总能找到方法来绕过WAF所设定的安全规则。


比如说,你可能会觉得Log4shell很好捕捉到,只检查“${jndi”就可以了,对吧?但不幸的是,Log4J支持嵌套“查询”,包括将字母转换为大写/小写的查找,例如“${lower:J}”。


这也就意味着,威胁行为者可以围绕每一个字符插入任意数量的嵌套查询,并执行攻击,比如说“${${lower:J}ndi:...”。当然了,这只是绕过WAF规则的其中一个例子罢了,类似的情况还有很多很多。


上面这个例子只是一个非常简单的语法,你可以想象一下像SQL和PHP这样复杂的语言还会产生多少种绕过策略,尤其是在威胁行为者具备过硬的编码技术时,这种情况将更加复杂。


另一种绕过WAF的方法就是将恶意字符Payload填充到请求的Body中,然后让它大小超过8KB。正如本文之前在性能部分提到的那样,请求Body必须缓冲到RAM中进行分析,因此WAF必须设置一个截止点,以避免在单个请求上花费无限的CPU和RAM。对于某些 WAF(例如AWS的WAF),该截止点约为8KB。因此,如果我们直接在Log4Shell攻击字符串前放置8192个良性的字符,那么就可以实现WAF绕过了。


WAF甚至可以被当作攻击向量


2019年,CapitalOne就曾遭遇过一次非常严重的数据泄露,而当时的这一次网络安全事件据说就是由于WAF的错误配置所造成的。研究人员透露称,威胁行为者当时成功地欺骗WAF并向EC2元数据服务发送了恶意请求,而该服务则允许威胁行为者直接从S3读取敏感的文件和凭证数据。

虽然这只是网络安全事件中的冰山一角,但这也说明了一个事实,即WAF实际上具有很大的攻击面。


大多数的WAF都是庞大而复杂的代码库,通常是闭源的,并且是用内存不安全的语言编写的。由于它们是昂贵的“企业”产品,企业会在其中塞满各种用户实际上并不需要的功能,以使它们的市场竞争力更强。但正是因为这些额外的功能,使得WAF反而变成了一个“危险”的安全工具,比如说SolarWinds。


但是目前互联网上有很多组织都在使用类似的商业安全软件,这些软件一旦部署并上线,每天都会解析和处理大量不受信任的输入,并会授权其访问所有后端服务器、日志记录基础设施、SIEM、警报系统,甚至JIRA的权限。毫无疑问,这已经成为了一件非常可怕的事情。


WAF误报率较高


在过去的二十年里,开源的WAF规则集得到了大规模扩展,而且也支持检测更新类型的网络威胁和攻击。显然,所有的这些WAF都在做同样的事情。这也就意味着, 越来越多的字符串可能会触发WAF的规则,并阻止我们的请求。如果你想发表一篇讨论Log4shell的文章或发表相关的评论,你可能会因为发表的内容中包含了“${jndi”之类的字符串而被WAF屏蔽。因此,随着新的规则不断增加,WAF的误报率自然会持续上升,并且根据研究人员维护ModSecurity的大量规则列表所得到的经验,这种误报率现在已经相当高了。



目前,社会出现了很多所谓的“下一代WAF”,它们声称可以通过查看和分析多个请求或使用IP信誉系统来解决这个问题,但实际上根本就无法解决。

除此之外,使用WAF还有一个最基本的问题,即安全防御者必须对WAF和安全工具进行完美的配置,才可能安全地避免误报出现。但是,威胁行为者只要找到其中一个漏洞或缺陷,你的安全防御就失去了意义。


WAF的替代方案


由于WAF消耗的资源多、运行效率低下、安全性不高且噪音大,那我们如何去说服安全管理层不要使用WAF呢?从技术层面上,我们将这种平替技术称之为“补偿控制”,之所以我们将其视作WAF的一种更强大的替代方案,原因如下:


1、隔离性:隔离涉及确保一个组件中的漏洞不会影响系统的其余部分,并且有许多技术可以提供隔离性。比如说,浏览器可以通过在特殊的沙盒进程中执行所有代码来实现这一点,这些进程无法全权访问 Cookie、保存的密码、其他选项卡等。想象一下,如果每段 JavaScript 都需要由数百个正则表达式进行分析,那么整个网络体验将会有多差。除此之外,微服务在设计时就考虑到了隔离性,但我们也可以使用各种库和编程语言从整体层面上实现隔离性。
2、不变性:我们可以通过删除一些假定条件来消除整个类型的攻击,比如说部署readOnlyRootFilesystem、需要重新启动的包管理器或不可变数据备份等。
3、静态分析功能:针对SQL注入其实有一个“灵丹妙药”,即使用“预先准备好的语句”。但问题是,很多开发人员可能会忘记使用它们。CI 管道中的静态分析检查几乎可以确保代码库中SQL注入漏洞为零,此时不需要任何SQL注入WAF规则。
4、基于功能的安全性:并非每个API节点都需要对整个数据库和文件系统具有不受限制的读/写访问权限,但这正是我们现在构建API的常用方式。通过代码编程能力,我们可以准确地让“GET /api/v1/books”只需要拥有对“books”表的读取权限。或者“POST /api/v1/imageupload”只需要对特定文件夹拥有写权限,同时不需要生成进程。


总结


我们也承认这些想法有些空泛,我们需要让这些控制措施去适应我们特定的应用程序,但这些设计安全的策略正是安全行业需要走向的方向。不幸的是,安全行业很难从基于设计的技术中获利。


参考资料


https://github.com/0xInfection/Awesome-WAF#evasion-techniques
https://logging.apache.org/log4j/2.x/manual/lookups.html
https://blog.cloudflare.com/exploitation-of-cve-2021-44228-before-public-disclosure-and-evolution-of-waf-evasion-patterns/
https://habr.com/en/companies/dsec/articles/454592/
https://docs.aws.amazon.com/waf/latest/developerguide/waf-oversize-request-components.html
https://www.macchaffee.com/blog/2023/solarwinds-hack-lessons-learned/
https://docs.fastly.com/en/ngwaf/jira
https://docs.fastly.com/en/ngwaf/about-next-gen-waf
https://docs.fastly.com/en/ngwaf/about-the-architecture#about-the-collection-and-analysis-system
https://www.ctrl.blog/entry/cloudflare-ip-blockade.html
https://github.com/dckc/awesome-ocap#libraries-and-frameworks
https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
https://thenewstack.io/3-immutable-operating-systems-bottlerocket-flatcar-and-talos-linux/
https://www.rsync.net/resources/faq.html#9a


参考链接


https://www.macchaffee.com/blog/2023/wafs/