What your web application firewall isn't telling you

Web Application Firewalls (WAFs) have played a role in trying to prevent web-based threats since the 1990s, acting as a front line defense in many cybersecurity strategies. However, limitations do exist. In this Ghost Labs article, we’ll delve into three of the crucial limitations of WAFs. This post highlights their challenges in detecting advanced threats due to evolving attack methodologies, the inadequacy in countering business logic attacks, and scalability and performance limitations. By understanding these limitations, organizations can adopt a more comprehensive and layered approach to web application security, ensuring that they remain ahead of malicious actors.

Demonstration

Click here if you’re already familiar with the advantages and disadvantages of WAFs and want to skip to the Ghost Labs WAF Bypass Toolkit.

A brief history of web application firewalls

Web Application Firewalls, commonly known as WAFs, serve as one of the foundational pillars of cybersecurity for modern online environments. Positioned between a user's web browser and a web application, WAFs act as gatekeepers, scrutinizing incoming web traffic to identify and block malicious requests. Their primary mission is to shield web applications and APIs from a variety of threats such as cross-site scripting (XSS), SQL injection, denial-of-service, and other web-based attacks that might exploit vulnerabilities in the application. By doing so, WAFs not only protect sensitive user data and maintain the integrity of the application, but also ensure that businesses can safely and confidently operate in the digital realm.

The Promise of WAFs: more hype than reality?

While WAFs are frequently lauded as the primary line of defense for web applications, if we take an honest assessment of the last two to three decades of cybersecurity innovation, one can't help but question if they truly live up to the hype. Touted as the vanguard against malicious HTTP traffic and queries, they do offer protection against some common vulnerabilities such as SQL injections and cross-site scripting attacks, however, relying solely on WAFs can give organizations a false sense of security. Despite the adaptive mechanisms of some more capable WAF technologies, which employ a mix of predefined rules and heuristic analysis, WAFs are not infallible. Their rulesets can be outdated, failing to catch newer, more sophisticated attack vectors. Furthermore, their heuristic methods, though adaptive, can be prone to false positives, leading to legitimate requests being blocked. This balance between being overly permissive and overly restrictive is a challenge WAFs have yet to master fully. While they undeniably offer a protective layer, positioning WAFs as the panacea for all web application threats may be more a product of marketing than reality.

Setting the Stage: No Security Solution is a Silver Bullet

As we delve into some of the specific traits of modern web application security, it's essential to acknowledge a fundamental truth: no singular security solution offers complete protection, WAFs included. Just as a castle's defense isn't solely reliant on a perimeter wall, web application and API security cannot hinge on the abilities of WAFs alone. Despite the high hopes placed upon web application firewalls, they are, in essence, just one component of a comprehensive security strategy. Cyber attackers continually refine their tactics, innovate, and find loopholes, necessitating a multi-layered approach to defense. Whether it's a zero-day vulnerability or a business logic attack that eludes signature-based detection, every security tool has its limitations. Recognizing these vulnerabilities and complementing WAFs with other security measures is the key to building a robust defense that adapts and evolves in tandem with the threat landscape.

Limitation 1 : Incomplete Visibility into Advanced Threats

False positives and negatives

Many security professionals still have the scar tissue from dealing with the frustration of false positives. These are essentially false alarms, wherein a WAF flags benign traffic as malicious. Imagine a genuine customer trying to place an order on your online store, only to be blocked by your WAF. Not only does this create a poor user experience and rob you of potential revenue, but it also demands manual effort to allowlist such benign behaviors, taking away precious time and resources from other security tasks.

On the flip side, false negatives pose an even more serious problem. This is essentially when malicious traffic is mistaken for legitimate traffic, allowing attackers to bypass the WAF altogether. If the WAF is too permissive, it risks letting threats in. The challenge here is striking a balance – setting the WAF to be restrictive enough to catch threats, but not so much that it disrupts regular business operations. This burden alone has created a situation where to be most effective, many WAF technologies require constant configuration, tuning, and attention. Resource constrained security teams often don’t have the necessary cycles to do this.

Evolving threats

In the ever-changing landscape of cybersecurity, attackers are constantly devising new methods to breach defenses. Traditional WAFs often rely on predefined signatures or known patterns of bad behavior. However, sophisticated attackers can cloak their malicious activities, making them appear like genuine requests.

Additionally, zero-day vulnerabilities – those for which no official fix is available yet – present a significant threat as well. Since they are previously unknown, traditional WAFs, which rely on known signatures, will likely not recognize or be able to defend against these attacks.

Moreover, with threats evolving at a rapid pace, keeping a WAF updated becomes a race against time. Cybersecurity teams need to continuously update their WAFs to ensure they are protected against the latest threats, a task that can be both time-consuming and challenging given the sheer volume and complexity of new vulnerabilities and attack vectors.

Limitation 2: Inadequate Protection Against Business Logic Attacks

Business logic attacks

Unlike traditional attacks that target known vulnerabilities or technical flaws in an application, business logic attacks focus on manipulating the application's intended behavior. Think of them as wolves in sheep’s clothing. They don’t kick down the door; they politely knock, dressed as someone you trust - an authenticated user. In simple terms, these types of attacks exploit the intended behaviors of an application or API to achieve malicious objectives. An example might be an attacker repeatedly using a password reset function to flood a user's email, or exploiting promotional offers by creating numerous fake accounts. We’ve seen real-world cases of business logic attacks like CVE-2021-4191, in which attackers were able to abuse the GitLab GraphQL API to enumerate user details without being authenticated.

WAFs and behavior-based recognition

Coercing a WAF to recognize business logic attacks is a tall order. This is primarily because from the perspective of the WAF, the requests made during such an attack would usually appear perfectly legitimate. For instance, if an attacker makes multiple valid purchases with the aim of understanding the pattern of transaction IDs, the WAF might see these as genuine transactions rather than a potential threat.

Some examples of business logic attacks include:

• Abusing application features: An e-commerce site might have a feature that allows users to compare two products side by side. An attacker could exploit this feature by rapidly requesting comparisons, overwhelming the system.
• Unexpected sequences of valid requests: Consider an online banking system where a user transfers money and then checks their balance. An attacker might reverse this sequence to check for vulnerabilities or system behaviors that could be exploited.
• Race conditions: These occur when a system’s behaviors can be altered by the timing of certain events. An attacker might try to initiate two simultaneous transactions to exploit a potential lapse in the application’s logic. This could be catastrophic in a commerce or banking system.

Limitation 3: Scalability and Performance Issues

WAFs can introduce latency as they inspect and process requests

Every request made to a web application goes through the WAF for inspection before reaching the application server. Each of these inspections, where the WAF checks the request against its rule set to determine if it's malicious, takes time. Even though this process might only add a few milliseconds, it can accumulate to material levels, especially during periods of high traffic. This addition to the request-response time is what users will ultimately experience  as latency.

The trade-offs between thorough inspection and keeping web applications responsive

For a WAF to be effective, it needs to be thorough, examining each incoming request for potential threats. However, this thoroughness can slow down the processing time. Web application and API administrators are often faced with the dilemma of choosing between a rigorous inspection—which might lead to slight delays in response time—and a faster, potentially less comprehensive check. In environments where real-time response is critical, like financial trading platforms or online gaming sites, even minor latencies can be detrimental.

The challenge of scaling WAFs with increased traffic, especially during traffic spikes or DDoS attacks

Traffic on the internet is often unpredictable. Events like product launches, promotional campaigns, or even news items can lead to sudden surges in visitors. In such situations, the WAF needs to handle an exponentially higher number of requests than usual, which can strain its resources. Even more daunting are Distributed Denial of Service (DDoS) attacks, where malicious actors deliberately flood a site or API with traffic, aiming to overwhelm it by starving it of resources. In such cases, the WAF not only needs to distinguish between legitimate and malicious requests, but also scale quickly to handle the sheer volume of incoming traffic.

Potential for degraded performance or missed threats during heavy loads

Under heavy loads, there's a risk that the WAF might become a bottleneck, causing delayed responses or even application timeouts. Furthermore, to cope with the volume, some WAFs might switch to a mode where they only check requests against a subset of their rules, potentially allowing some threats to slip through. There's always a trade-off: the more comprehensive the check, the more processing power it requires, and under high loads, this can lead to performance degradation.

Demonstration

With the details and limitations of WAF technologies thoroughly covered, let’s look at a real-world example to understand how some of these limitations can impact your ability to engineer adequate detection and protection strategies for your modern web applications and APIs.

Let’s first take a look at the max payload inspection sizes for some common WAF providers as of this writing.

The max payload inspection size means the WAF will simply ignore payload contents beyond the specified size. These values are generally known and publicly documented, but the limitation and the behavior in handling large payloads should be considered when evaluating the effectiveness of the WAF implementation.

The Ghost Security Research Team - Ghost Labs - has created a simple toolkit to test the effectiveness of your WAF implementation. Introducing the WAF Bypass Toolkit - WAF BTK for short.

Using WAF BTK as a local MITM proxy allows you to quickly see the effects of triggering a bypass of any given WAF. In the following walkthrough, we’ve configured an AWS WAF with the recommended ruleset for demonstration purposes.

Step 1 - start the proxy

With the proxy running, it acts as a “bump in the wire”, modifying the request along the way to the server. It is designed with the Unix tool philosophy in mind, such that its output can be chained with other proxy tools upstream to accommodate any custom workflow.

Step 2 - send a normal request

With a normal request, we can see the AWS WAF blocked the malicious request as intended due to the payload containing a suspicious SQL reconnaissance fragment.

Step 3 - send a padded request

To send a padded request which will bypass WAF inspection, we set a special header waf-btk-padding. This header controls the amount of padding applied to the payload, and is then stripped from the request sent to the server. In the above example, we can see the WAF rule that looks for suspicious SQL fragments was bypassed and the API responded normally.

In this example, we specifically targeted an AWS WAF, but  you can apply the same technique to most WAF implementations.

Further Research

As mentioned above, these limitations are well known and publicly available. However, using a tool like WAF BTK highlights just how easily these limitations could be exploited by an attacker. This is why it is crucial to consider modern security strategies that leverage behavioral analysis and rich environmental context to bring dynamic security detection capabilities to your web applications and APIs.

In part two of this series we’ll look further into how attacks can exploit similar limitations in WAF inspection of malicious headers and cookie payloads. Stay tuned for the next article!