Why WAFs Are Not Enough

TL;DR:

• WAFs are crucial for web application security but have limitations
• WAFs can be bypassed, do not protect against zero-day exploits, and require maintenance
• Other security systems like WAAP, RASP, and IDPS are needed to enhance security
• Secure practices like input sanitization and pentesting are also essential
• WAFs alone are not enough for comprehensive web application security.

Web applications have become one of the most important assets of almost every business today. And one of the most popular ways to protect them is WAF (Web Application Firewall). Is a WAF enough to protect my web application? We'll answer this question and more in this blog post

We’ll start by understanding what WAFs are and why companies use them. Then look into firewall limitations to understand why they aren’t enough, and end with some other systems you should consider using along with WAF security.

Why WAFs Are Not Enough: Understanding Their Limitations

Before we get into what WAFs are, let’s first address the question “What is a firewall?”

A firewall is a security system that controls traffic. It is a device that monitors traffic and decides whether to allow that traffic or block it based on certain rules. Are WAFs enough to protect my web application? We'll answer this question and more in this blog post. A firewall sits between devices or networks and can control the traffic that’s flowing either way.

WAFs (Web Application Firewalls) are more focused on protecting web applications by applying their rules to HTTP traffic. On one side WAFs have a web application and on the other side, the users that communicate with the web application - traffic from the internet. WAFs monitor HTTP traffic and can detect and prevent attacks that occur through HTTP requests such as SQL Injection and Cross-site Scripting.

Why Companies Relying Solely on WAFs May Be at Risk

A successful cyberattack on web applications might lead to serious losses in business and reputation for enterprises. Therefore companies need to make sure to secure their web applications.

Let’s say you’re running an online platform that provides some kind of data for users. One day you notice that you’ve started getting more than usual traffic. At first, you think that’s good news because it’s more traffic. But after a little digging into the logs and checking up threat intelligence sources, you realize that the increased traffic is mostly from badly reputed IPs that have been reported for scanning, brute-forcing, and DoS. Not good news, is it? However, you were smart enough to use a WAF for your web application so you add these IPs to the blocklist and the bad traffic is taken care of.

You can use WAFs for such simple use cases as blocking or whitelisting IPs to control access to your application or you can go a bit more advanced to configure WAFs to block attacks.

Here’s an example of a ModSecurity rule to block one method of SQL injection attacks:

SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|!REQUEST_COOKIES:/_pk_ref/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "@rx (?:\b(?:having\b ?(?:[\'\"][^=]{1,10}[\'\" ?[=<>]+|\d{1,10} ?[=<>]+)|(?i:having)\b\s+(?:'[^=]{1,10}'|\d{1,10})\s*?[=<>])|exists\s(?:s(?:elect\S(?:if(?:null)?\s\(|concat|top)|ystem\s\()|\b(?i:having)\b\s+\d{1,10}|'[^=]{1,10}'|\sselect)|(?i:\bexecute\s{1,5}[\w\.$]{1,5}\s{0,3})|(?i:\bcreate\s+?table.{0,20}?\()|(?i:\blike\W*?char\W*?\()|(?i:select.*?case)|(?i:from.*?limit)|(?i:\bexecute\()|(?i:order\sby))"

Companies use WAFs as a security mechanism to prevent attacks and block threats. But are WAFs enough to secure your web applications? Not really. WAF security only goes to an extent. So where does WAF security stop?

The Insufficient Protection Offered by WAFs in Security Measures

Although WAFs are beneficial and have become an integral part of security in almost every organization, they’re not enough. Let’s look into some limitations of why WAFs don’t provide complete security.

How WAF Vulnerabilities Can Lead to Bypassing Security Measures

WAFs feed on configurations and rules. It goes by the string/character and not always by what the request intends to do. Therefore WAFs can be bypassed by manipulating the payload. There are various techniques you can use to bypass firewalls and because various cheat sheets are available online, it makes it even easier for attackers. Let’s look into some WAF bypass techniques to understand better.

Exploring Nested Encodings as a Vulnerability in WAFs

Let’s say the payload includes

<script>confirm()</script>

The WAFs can likely block this. But what if we encode this?

%3Cscript%3Econfirm()%3C%2Fscript%3E

You can also add a rule to block the encoded payload. But think about how many rules you’d have to add to block every encoded version of a payload. And even if you went ahead and added rules for some encoded versions of a payload, it’s practically impossible to add rules to prevent every payload. Therefore WAFs don’t protect all levels of nested encodings.

If you’re interested to learn more about payloads for bypassing WAFs, here are some links:

• How to Bypass WAF. HackenProof Cheat Sheet
• WAF-bypass-Cheat-Sheet
• SQL Injection Bypassing WAF

Understanding the Risks of Fail Open and Fail Close in WAFs

Most WAFs come with fail open and fail close settings to handle software/hardware failures. Fail open is when the WAF remains open on system failure allowing all traffic to go through. Fail close is when the WAF blocks all traffic. You can execute a DoS or DDoS attack on the WAF to force WAF to go into a fail-open state which will let you bypass the WAF. And if it goes into a fail close, then the operation is affected.

The Impact of Request Size on WAF Effectiveness

WAFs have a limitation on the bytes of the requests they check. This limitation ranges from 8 KB to 128 KB for most WAFs and is set to 128 KB by default. An attacker can leverage this to place the malicious part of the request further in the request to bypass WAF security.

The Inability of WAFs to Safeguard Against Zero-Day Exploits

A zero-day is a vulnerability that attackers discover before the stakeholders are aware of it. And because it is unknown, there are no mitigations for it. As WAFs need to be configured to detect and block dangerous traffic, they can’t defend against attacks to exploit zero-day vulnerabilities.

Also, what if there are underlying vulnerabilities coded right into the application? A WAF will do nothing to detect/prevent that.

Challenges in Maintenance and Performance with WAFs

WAFs are not one-time configured systems. Once WAFs are set up, you need to update the rules as and when new threats surface. Along with this, you also need to patch WAFs to get rid of security and functionality weaknesses. With the frequent change in attack techniques, you might need to upgrade your WAFs and add more features to work with WAFs. All of this calls for more maintenance burden.

WAFs’ performance is inversely proportional to the number of rules. The more rules, more the time WAFs take to investigate the traffic and decide to allow or block it. Therefore, a high-coverage WAF will impact the performance and user experience.

The Gap in API Security Coverage by WAFs

We live in a world where web application communication makes use of multiple protocols. They’re not just limited to HTTP requests. With the increased usage of APIs, a good number of attacks are executed using APIs. Most WAFs by default can parse JSON and REST but there are very few WAFs that can parse other data protocols.

These are some of the limitations of WAFs. This section clearly shows why just WAFs aren’t enough. Although WAFs provide good security measures, they’re not enough. They are being defeated every day. So what else should you consider?

Enhancing Security Beyond WAF: Essential Measures to Implement

Many attacks can be executed against an application that is beyond the capabilities of a WAF. WAFs are needed, but you need evolved WAFs or more systems in addition to WAFs to enhance security.

WAAP (Web Application and API Protection)

APIs have become an integral part of web applications these days. Therefore API security is also crucial. WAAPs are evolved versions of WAFs that along with protecting web applications, focus on API security.

RASP (Runtime Application Self-Protection)

RASP aims to protect the application while the application is running by analyzing the behaviour of the application and identifying malicious behaviour. It helps you fight against zero-day, internal, and external threats. RASP uses the application’s logic and the context to decide what’s malicious. You can configure RASP to send an alert or block the threat when it detects one.

IDPS (Intrusion Detection and Prevention System)

IDPS is placed after WAFs closer to the application or internal network of the organization. While WAFs focus on HTTP traffic, IDPS focuses more on network protocols such as DNS, SMTP, RDP, SSH, etc. IDPS acts as a strong support for WAF. Therefore WAF and IDPS complement each other and improve overall security.

Secure Practices

The above systems help in covering some aspects that WAFs are not fully able to. The main idea is to cover WAF blindspots. So in addition to these systems, certain security implementations such as input sanitization will help you further prevent attacks.

Sanitizing client-side data by whitelisting inputs, scrubbing bad values, HTML encoding values, etc., is a must for web application security. Of course, this adds to the developers' workload but the pros of such secure implementation outweigh the cons. And pentesting your implementations and improving them will further enhance security.

Conclusion

Web application security is a must. A WAF is a must for web application security. Through this post, we understood what WAFs are and why companies use them (or why companies should use them if they don’t already). Although WAFs help with web application security, they’re not enough. We looked into some WAF security limitations to support that statement.

While WAFs by themselves don’t provide enough security, you can use some other systems such as RASP, WAAP, and IDPS to enhance security. And along with these, other practices such as pentesting, secure code reviews, using security frameworks, and security best practices will be of great. Interested to learn more? Check out this post What is Penetration Testing, and How Does It Work?