Learn about what WAFs are and why companies use them and why they’re not enough to protect your organization, and what else you can use.
TL;DR:
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.
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.
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?
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 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.
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:
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.
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.
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.
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.
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?
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.
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 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 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.
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.
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?
Security
Can be easily manipulated without detection if not properly secured.
Digitally signed and can be validated on the server. Manipulation can be detected.
Size
Limited to 4KB.
Can contain much more data, up to 8KB.
Dependency
Often used for session data on the server-side. The server needs to store the session map.
Contains all the necessary information in the token. Doesn’t need to store data on the server.
Storage Location
Browser cookie jar.
Local storage or client-side cookie.
No testing strategy is one-size-fits-all. Pentesting in a production environment can provide advantages, though it does come with many risks.
Providing the quality of the biggest names in security without the price tag and complications.
Manual penetration testing
Full time Canadian hackers
Remediation support
