Why WAFs Are Not Enough

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.

What is a WAF? Why do Companies Use Them?

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. 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 do Companies use WAFs?

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, bruteforcing, and DoS. Not really 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 advance 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?

Limitations of WAF for Security

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.

WAFs can be Bypassed

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.

Nested Encodings

Let’s say the payload includes

<script>confirm()</script>

It’s highly likely that the WAFs can 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 provide protection against 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

Fail Open and Fail Close

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.

Request Size

WAFs have a limitation on the bytes of the request 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.

Does Not Protect 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 basically do nothing to detect/prevent that.

Maintenance and Performance

WAFs are not one-time configure 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.

Lack of API Security

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 are able to parse JSON and REST but there are very few WAFs that are able to 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?

What Other Security Should You Have Besides WAF?

There are many attacks that can be executed against an application that is beyond the capabilities of a WAF. WAFs are definitely 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 at protecting the application while the application is running by analyzing the behavior of the application and identifying malicious behavior. 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. And 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, 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 these posts:

• 3 FinTech Application Security Best Practices
• Secure Application Configuration Basics
• Application Security Code Review Introduction
• What is Penetration Testing, and How Does It Work?
• NIST SP 800-115