Blog
What your web application firewall isn't telling you
·
Tuesday, October 10, 2023
Josh Larsen
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 (DoS) Attacks
Other Web-Based Attacks
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, an honest assessment of the last two to three decades of cybersecurity innovation raises questions about whether they truly live up to the hype. Key points include:
Protection Against Common Vulnerabilities:
Effective against SQL injections and XSS attacks.
Limitations:
Outdated Rulesets: Struggle to catch newer, more sophisticated attack vectors.
False Positives: Legitimate requests may be blocked, degrading user experience.
False Negatives: Malicious traffic can bypass WAFs if they are too permissive.
Adaptive Mechanisms:
Use a mix of predefined rules and heuristic analysis.
Despite adaptability, WAFs are not infallible.
Conclusion: While WAFs offer a protective layer, positioning them as the sole solution for all web application threats may be more a product of marketing than reality.
Setting the Stage: No Security Solution is a Silver Bullet
It's essential to acknowledge a fundamental truth in modern web application security:
No singular security solution offers complete protection, WAFs included.
Multi-Layered Defense:
Just as a castle's defense isn't solely reliant on a perimeter wall, web application and API security cannot hinge on WAFs alone.
Evolving Threats:
Cyber attackers continually refine their tactics, innovate, and find loopholes.
Comprehensive Security Strategy:
Complement WAFs with other security measures to build a robust defense that adapts and evolves with the threat landscape.
Limitations of WAFs
Limitation 1: Incomplete Visibility into Advanced Threats
False Positives and Negatives
False Positives:
Definition: Legitimate traffic flagged as malicious.
Impact: Poor user experience, potential revenue loss, and increased manual effort to allowlist benign behaviors.
False Negatives:
Definition: Malicious traffic mistaken for legitimate traffic.
Impact: Attackers can bypass the WAF, posing significant security risks.
Balancing Act:
Setting the WAF to be restrictive enough to catch threats without disrupting regular business operations is challenging.
Resource Strain: Constant configuration, tuning, and attention required, which can be burdensome for resource-constrained security teams.
Evolving Threats
Sophisticated Attack Techniques:
Attackers can cloak malicious activities to appear as genuine requests.
Zero-Day Vulnerabilities:
Definition: Vulnerabilities for which no official fix is available yet.
Impact: Traditional WAFs, relying on known signatures, cannot recognize or defend against these attacks.
Continuous Updates Needed:
Keeping WAFs updated against the latest threats is time-consuming and challenging due to the volume and complexity of new vulnerabilities and attack vectors.
Limitation 2: Inadequate Protection Against Business Logic Attacks
Business Logic Attacks
Definition: Attacks that manipulate an application's intended behavior rather than exploiting technical vulnerabilities.
Examples:
Repeatedly using a password reset function to flood a user's email.
Exploiting promotional offers by creating numerous fake accounts.
Real-World Case: CVE-2021-4191 – Abuse of the GitLab GraphQL API to enumerate user details without authentication.
WAFs and Behavior-Based Recognition
Challenge:
Requests made during business logic attacks appear legitimate to WAFs.
Examples of Business Logic Attacks:
Abusing Application Features: Rapidly requesting product comparisons on an e-commerce site to overwhelm the system.
Unexpected Sequences of Valid Requests: Reversing transaction sequences in an online banking system to exploit vulnerabilities.
Race Conditions: Initiating simultaneous transactions to exploit potential lapses in application logic, which can be catastrophic in commerce or banking systems.
Conclusion: Coercing a WAF to recognize business logic attacks is difficult because the malicious requests often appear legitimate, requiring more sophisticated detection mechanisms.
Limitation 3: Scalability and Performance Issues
WAFs Can Introduce Latency
Inspection Process:
Every request is inspected against the WAF's ruleset, adding processing time.
Impact:
Even a few milliseconds per request can accumulate during high traffic periods, leading to noticeable latency for users.
Trade-Offs Between Thorough Inspection and Responsiveness
Dilemma:
Thorough Inspection: May lead to slight delays in response time.
Faster Checks: Potentially less comprehensive, increasing security risks.
Critical Environments:
Real-time response is essential in financial trading platforms or online gaming sites, where even minor latencies can be detrimental.
Scaling Challenges During Traffic Spikes or DDoS Attacks
Unpredictable Traffic:
Events like product launches or promotional campaigns can cause sudden surges in traffic.
DDoS Attacks:
Malicious actors flood a site or API with traffic to overwhelm resources.
WAF Responsibilities:
Distinguishing between legitimate and malicious requests.
Scaling quickly to handle high volumes of incoming traffic.
Potential for Degraded Performance or Missed Threats During Heavy Loads
Bottlenecks:
Under heavy loads, WAFs might cause delayed responses or application timeouts.
Reduced Inspection:
Some WAFs may switch to checking requests against a subset of rules to cope with high volumes, potentially allowing threats to slip through.
Trade-Off:
More comprehensive checks require more processing power, leading to performance degradation under high loads.
Demonstration: Ghost Labs WAF Bypass Toolkit
With the limitations of WAF technologies thoroughly covered, let's explore a real-world example to understand how these limitations can impact your ability to engineer adequate detection and protection strategies for modern web applications and APIs.
Max Payload Inspection Sizes for Common WAF Providers
ProviderMax Payload InspectedAWS WAF8kCloudflare128kGoogle Armor8kAzure WAF128k
Note: The max payload inspection size means the WAF will ignore payload contents beyond the specified size. These values are generally known and publicly documented, but this limitation and the behavior in handling large payloads should be considered when evaluating the effectiveness of a WAF implementation.
Introducing the Ghost Labs WAF Bypass Toolkit (WAF BTK)
The Ghost Security Research Team - Ghost Labs has developed a simple toolkit to test the effectiveness of your WAF implementation: the WAF Bypass Toolkit (WAF BTK).
Using WAF BTK as a Local MITM Proxy
WAF BTK allows you to quickly observe the effects of triggering a bypass of any given WAF. Below is a walkthrough using AWS WAF with the recommended ruleset for demonstration purposes.
Step 1: Start the Proxy
bashCopy codemake run 2023/04/24 17:17:15 [info] start listening to 127.0.0.1:8888 ...
View rawstart.sh hosted with ❤ by GitHub
Description:
The proxy acts as a “bump in the wire,” modifying requests en route to the server.
Designed with the Unix tool philosophy, allowing chaining with other proxy tools upstream to accommodate custom workflows.
Step 2: Send a Normal Request
bashCopy codecurl -k -x http://localhost:8888 'https://api.ghostbank.com/api/v3/transfer' \ -H 'authority: api.ghostbank.com' \ -H 'accept: application/json' \ -H 'accept-language: en-US,en;q=0.9' \ -H 'content-type: application/json' \ -H 'cookie: ghostbank=MTY4MTk4NzQ5M...Oj4UoQKVK1U=' \ -H 'origin: https://ghostbank.com' \ -H 'referer: https://ghostbank.com/' \ -H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36' \ --data-raw '{"account_to":1000,"account_from":1999,"amount":7,"query":"SELECT * FROM schema"}' \ --compressed
Response:
jsonCopy code{"error":"WAF block"}
View rawrequest.sh hosted with ❤ by GitHub
Explanation:
The AWS WAF successfully blocked the malicious request containing a suspicious SQL reconnaissance fragment.
Step 3: Send a Padded Request
bashCopy codecurl -k -x http://localhost:8888 'https://api.ghostbank.com/api/v3/transfer' \ -H 'waf-btk-padding: 8' \ -H 'authority: api.ghostbank.com' \ -H 'accept: application/json' \ -H 'accept-language: en-US,en;q=0.9' \ -H 'content-type: application/json' \ -H 'cookie: ghostbank=MTY4MTk4NzQ5M...Oj4UoQKVK1U=' \ -H 'origin: https://ghostbank.com' \ -H 'referer: https://ghostbank.com/' \ -H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36' \ --data-raw '{"account_to":102,"account_from":998,"amount":7,"query":"SELECT * FROM schema"}' \ --compressed
Response:
jsonCopy code{"status":"ok"}
View rawrequest.sh hosted with ❤ by GitHub
Explanation:
By sending a padded request with the special header
waf-btk-padding, the WAF bypasses inspection.The WAF rule targeting suspicious SQL fragments was bypassed, and the API responded normally.
Note: While this example specifically targets an AWS WAF, the same technique can be applied to most WAF implementations.
Further Research
The limitations of WAFs are well-known and publicly available. However, tools like WAF BTK highlight how easily these limitations can be exploited by attackers. This underscores the importance of considering modern security strategies that leverage:
Behavioral Analysis
Rich Environmental Context
These strategies bring dynamic security detection capabilities to your web applications and APIs.
Stay Tuned: In part two of this series, we’ll explore how attacks can exploit similar limitations in WAF inspection of malicious headers and cookie payloads. Don’t miss the next article!
Editor's Note: This blog was originally published on October 25, 2023, and has been updated for accuracy and completeness.
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. Provider Max Payload Inspected AWS WAF 8k Cloudflare 128k Google Armor 8k Azure WAF 128k 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!
