Stop deploying web application firewalls

I wanted to write this because I don’t hear enough real people discouraging the use of Web Application Firewalls (WAFs). Probably because the search results for “Web Application Firewall” are all written by WAF vendors. Anyone reading just that could conclude that WAFs are a good idea. I’m here to offer another perspective, after having suffered through using a WAF for two years.

Web Application Firewalls were created early in the Internet’s history, especially popularized by the ModSecurity project in 2002. WAFs essentially work by intercepting every single HTTP request (and sometimes responses too) and evaluating several hundred regular expressions over the URI, headers, and body, sometimes aided by machine learning. If the request kinda looks like SQL, shell code, etc., the server may block your request.

In the infancy of the cybersecurity field, WAFs seemed like a good idea. HTTP requests were tiny, infrequent, and mostly contained mundane form data. But today, WAFs have overstayed their welcome in the security toolbelt. There are better techniques you can use that make even the most advanced WAFs entirely obsolete.

WAFs have Horrible Performance

Since WAFs run hundreds of regular expressions on every request, you may ask, “isn’t that super inefficient?” Yes, very.

Average time taken to upload 9,462 text files
7.36 4.55
Average requests per second
1285 2079
Number of requests blocked erroneously
5 0
Peak nginx CPU during trial
试用期间的nginx CPU峰值
73% 8%
Specifics about the benchmark

In addition to slowing down every request, you also need significant additional RAM for buffering requests. Since not a single byte in the buffer can be flushed to the backend server until the WAF completes its analysis, you need several gigabytes of RAM to store request bodies. Servers like nginx buffer requests by default, but enough large concurrent requests (like pushing a container image) can make a buffering web server run out of RAM. When using a WAF, every server becomes a buffering web server, which is simply incompatible with many types of applications.

I know computers are fast and hardware is cheap, but we shouldn’t be spending that kind of CPU and RAM on WAFs unless they’re a really effective security tool. But they aren’t, as you’ll see next.

WAFs are Easily Bypassed

WAF vendors and attackers are locked in a constant arms race, but it seems attackers are much better armed. How could they not be? Many of the attacks that a WAF purports to block involve complex grammars like SQL, shell code, and entire programming languages. They often include comments, character escaping, encoding issues, and more oddities. These oddities mean that attackers always have a significant advantage and can typically bypass any WAF rule if they are clever enough.

For example, you might think Log4shell is pretty easy to catch: just check for ${jndi, right? Unfortunately, Log4J supports nested “lookups“, including ones that convert letters to upper/lower case like ${lower:J}
例如,您可能认为Log 4shell很容易捕获:只需检查 ${jndi ,对吗?不幸的是,Log4J支持嵌套的“查找”,包括将字母转换为大写/小写的查找,如 ${lower:J}

That means an attacker can insert an arbitrary number of nested lookups around each letter and still perform the attack, like this: ${${lower:J}ndi:.... This lead CloudFlare to say “WAF vendors need to be looking at any occurrence of ${ and treating it as suspicious”, which is just another hilarious example of how WAFs can never live up to the expectations placed on them.
这意味着攻击者可以在每个字母周围插入任意数量的嵌套查找,并仍然执行攻击,如: ${${lower:J}ndi:... 。这导致CloudFlare说“WAF供应商需要关注 ${ 的任何事件并将其视为可疑”,这只是WAF如何永远无法达到对他们的期望的另一个滑稽的例子。

I just discussed the fairly simple grammar that is Log4J Lookups, but you can imagine how many more evasion tactics you could use in a language as complex as SQL or PHP, especially when considering encoding tricks. For an in-depth description of specific WAF bypass techniques, check out this awesome post.
我刚刚讨论了相当简单的语法,即Log4J Lookups,但是您可以想象在像SQL或PHP这样复杂的语言中可以使用多少规避策略,特别是在考虑编码技巧时。有关特定WAF旁路技术的深入描述,请查看这篇令人敬畏的文章。

Another way to bypass a WAF involves just padding your attack string to appear >8KB or so into the request body. Like I mentioned in the section on performance, request bodies must be buffered into RAM for analysis, so WAFs must choose some cut-off point to avoid spending infinite CPU and RAM on a single request. For some WAFs like AWS’s, that cutoff point is around 8KB. So if you just put 8192 innocuous characters before your Log4Shell attack string, you’ve rendered the WAF worthless.

WAFs are an Attack Vector

In 2019, CapitalOne experienced a breach of 100 million credit applications that was allegedly caused by a WAF misconfiguration. The attacker allegedly tricked the WAF into sending requests to the EC2 Metadata Service, which handed out a credential that allowed reading sensitive files from S3.

While this is just one example, it illustrates the curious fact that WAFs actually have a large attack surface.

Most WAFs are giant, complex codebases that are usually closed-source and written in memory-unsafe languages. Since they’re expensive “enterprise” products, companies stuff them full of unnecessary features to make them stand out more than competitors. All of this adds up to make WAFs yet another example of a dangerous “security” tool, just like SolarWinds.

No security officer would approve taking such a risky piece of software, putting it directly on the internet, making it parse mountains of untrusted input, and giving it access to all your backend servers, logging infra, SIEM, alerting systems, and even JIRA for some reason UNLESS it’s covered in security buzzwords and costs 5-6 figures per year.

Somehow, companies that sell security products have gotten a pass on implementing foundational security principles like secure by default, secure by design, attack surface reduction, and the principle of least privilege. Don’t let them keep getting away with that.

WAFs have a High False Positive Rate

Over the last twenty years, open-source WAF rulesets have expanded considerably to detect more-recent types of attack. Apparently all those proprietary WAFs are doing the same. That means there are more and more possible strings that could trigger a WAF to block your request. If you want to write a comment on an article discussing Log4shell, you might be blocked for including the string ${jndi in your comment. So naturally the false positive rate continues to rise with every new rule, and it’s already quite high based on my experience maintaining a giant list of ModSecurity rule exceptions.
在过去的二十年里,开源WAF规则集已经大大扩展,以检测更新类型的攻击。显然,所有这些专有的WAF都在做同样的事情。这意味着有越来越多的可能字符串可以触发WAF阻止您的请求。如果你想在一篇讨论Log4shell的文章上写评论,你可能会因为在评论中包含字符串 ${jndi 而被阻止。因此,随着每一个新规则的出现,误报率自然会继续上升,根据我维护ModSecurity规则异常的巨大列表的经验,误报率已经相当高了。

So-called “next-generation” WAFs claim to solve this problem by looking at multiple requests or by using IP reputation systems. While these can improve false positive rates, they can never truly solve the problem. In some ways, less false positives can increase the impact of particular false positives since neither users nor support teams have a clear procedure for fixing it. CloudFlare’s algorithm can randomly decide to block you and you will have no recourse. Imagine that happening to someone less tech-savvy.

This is the classic problem with using an outdated security tool like a WAF: defenders have to configure the tool absolutely perfectly to be safe and avoid false positives, but attackers just need to find a single weakness. Those are horrible odds. You should use alternatives that don’t require perfection from imperfect humans.

Alternatives to WAFs WAF的替代品

Since WAFs are resource-hungry, inneffective, unsafe, and noisy, how do I convince an auditor to not make me use one? The technical term would be to use “compensating controls”, but that sounds like such a weak term to describe the powerful and simple alternatives to WAFs I’m about to describe:

  • Isolation: Isolation involves ensuring that a breach in one component can not affect the rest of the system, and there are many technologies that provide isolation.

    • Browsers do this by executing all code inside special sandboxed processes that don’t have carte blanch access to cookies, saved passwords, other tabs, etc. Imagine how slow the web would be if every piece of JavaScript needed to be analyzed by hundreds of regexes before being executed!
      浏览器通过在特殊的沙盒进程中执行所有代码来实现这一点,这些沙盒进程没有对cookie、保存的密码、其他选项卡等的carte blanch访问权限。想象一下,如果每一段JavaScript在执行之前都需要经过数百个正则表达式的分析,那么Web将有多慢!
    • Microservices are designed with isolation in mind, but you can also do it in a monolith with a variety of libraries and languages.
  • Immutability: Entire classes of attack can be eliminated by removing a few assumptions, like having a readOnlyRootFilesystem, a package manager that requires rebooting, or append-only/immutable backups.
  • Static Analysis: SQL injection has a miracle cure called “prepared statements”. The problem is that devs forget to use them. Static analysis checks in a CI pipeline can all but ensure that zero SQL injection vulnerabilities are in your codebase, at which point there is no need for any SQL injection WAF rules. No, “defense in depth” is not a valid excuse to use a WAF anyway, because it provides no real defense! Like surrounding Fort Knox with an army of guard guinea pigs.
  • Capability-based security: Not every API endpoint needs to have unrestricted read/write access to your entire database and file system, but that is the normal way people build APIs today. By using capabilities, you can express exactly that “GET /api/v1/books” only needs read access to the “books” table. Or that “POST /api/v1/imageupload” needs write access to a specific folder, but doesn’t need the ability to spawn processes.
    基于能力的安全性:并非每个API端点都需要对整个数据库和文件系统具有不受限制的读/写访问权限,但这是当今人们构建API的正常方式。通过使用功能,您可以准确地表示“GET /API/v1/books”只需要对“books”表的读访问。或者“POST /API/v1/imageupload”需要对特定文件夹的写入权限,但不需要派生进程的能力。

Now I’ll admit these ideas are quite broad; you’ll need to adapt them to your particular app. WAF vendors offer a one-WAF-fits-all fantasy that I can’t match. But these secure-by-design strategies are the way that the security industry needs to be heading. Unfortunately, it’s a lot harder for the security industry to profit off of design-based techniques, so don’t hold your breath.

原文始发于Mac’s Tech Blog:Stop deploying web application firewalls

版权声明:admin 发表于 2024年2月8日 上午8:34。
转载请注明:Stop deploying web application firewalls | CTF导航