Web应用防火墙的使用效率问题与替代性技术的深入讨论

FB客服

发布于 2024-03-01 14:49:49

1060

发布于 2024-03-01 14:49:49

文章被收录于专栏：FreeBufFreeBuf

写在前面的话

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

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

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

Web应用防火墙的性能问题

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

	WAF	无WAF
上传 9,462 个文本文件的平均时间	7.36	4.55
每秒平均请求数	1285	2079
错误阻止的请求数	5	0
试用期间Nginx CPU峰值	73%	8%

除了对每个请求进行处理会减慢速度之外，我们还需要大量额外的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