Will real-time data processing replace batch processing?
At Confluent's user conference, Kafka co-creator Jay Kreps argued that stream processing would eventually supplant traditional methods of batch processing altogether.
Absolutely: Businesses operate in real-time and are looking to move their IT systems to real-time capabilities.
Eventually: Enterprises will adopt technology slowly, so batch processing will be around for several more years.
No way: Stream processing is a niche, and there will always be cases where batch processing is the only option.
Frontend Development / Security

How Attackers Bypass Commonly Used Web Application Firewalls

Many web application firewalls, or WAFs, are easily bypassed by attackers. Learn how to tell if your WAF is vulnerable and how to fix it.
Sep 13th, 2023 8:31am by
Featued image for: How Attackers Bypass Commonly Used Web Application Firewalls
Feature image by Lloyd Aloysius on Unsplash.  

Cloud-based web application firewalls (WAFs) sport an impressive array of protections. Yet many hackers claim they can easily bypass even the most sophisticated WAFs to execute attack queries against protected assets with impunity.

The threat research team atNetScaler, an application delivery and security platform, found that many cloud-based WAFs can be readily circumvented. If you have committed to paying for a WAF service, you need to run tests to ensure that your WAF can do — and is doing — what it’s supposed to do to protect your applications and APIs.

If you take away nothing else, I implore you to run some easy tests against your environment to check that your WAF service is protecting optimally. At the end of this article, I’ve outlined a few simple but often-overlooked steps to help you identify if someone is already bypassing your WAF and compromising the security of your web applications and APIs. But first, let’s look at the most common ways that attackers get around WAF defenses.

The Most Common WAF Attacks

Cloud-based and on-premises WAFs are security solutions delivered as a service that helps protect web applications and APIs from a variety of attacks that are documented by the Open Web Application Security Project (OWASP). The most common WAF attacks include:


When it comes to robbing a ton of data through a keyhole like a web application, then SQL injection is the way to go. Injection attacks were first documented more than 25 years ago and are still commonly used today.

The beginning of a database query is often designed to retrieve all information, followed by a filter to only show one piece of information. For example, a commonly used query is one that initially retrieves all customer information but then filters for a specific customer ID. The database executes this command against every line in the table and will return the requested information on the table row(s) where this statement is true. Usually, this is one single row. Attackers manipulate the form fields that are used to populate such queries to insert database commands, resulting in a statement that evaluates to true for every row in the table, which returns the contents of the entire table in the response. In an ideal world, developers would always secure their forms, so injection attacks would not be possible. However developers can be prone to error on occasion, so not all form fields are protected all of the time.

The latest OWASP Top Ten list now includes cross-site scripting in its injection category. Cross-site scripting is where attackers insert their scripts into your website or your web URLs so that unsuspecting victims execute them in their browsers, allowing attackers to transmit cookies, session information, or other sensitive data to their own web servers.

Broken Access Control

Broken access control allows an attacker to act outside of the intended expected behavior of the application or API developer. This vulnerability can lead to unauthorized information disclosure, modification or destruction of all data, and the ability to perform a business function outside the user’s limits, with some exclusive to APIs.

OWASP recently raised the criticality of broken access control to number 1 on its top 10 list of web application vulnerabilities. The reason for its newfound importance lies in the fact that this vulnerability category is especially applicable to APIs — a relatively new vector compared to web applications, which have been around for a long time. Attackers find APIs and attempt to exfiltrate information from them. And because APIs are not designed for human input, the same sort of validation inputs and checks used for web applications may not be top of mind for developers. Sometimes APIs are published without the knowledge of the security and operations teams.

Vulnerable and Outdated Components

Whenever a new vulnerability is found in a commonly used component, it results in a massive spate of bot-generated traffic scanning the internet, looking for systems that can be compromised. If you set up a web server and make it available to the internet, you will quickly see log entries for requests made to specific types of applications that do not exist on your newly created web server. This activity is simply the hacker network casting a wide net looking for vulnerable servers to harvest.

The primary function of a WAF is to examine the contents of an HTTP request — including the request body and request headers where the attack payloads are located — and decide if the request should be allowed or blocked. Some WAFs will also inspect responses to assess if there is an unauthorized leaking of data or sensitive information. They will also record the response structure (a web form or cookies, for example), which effectively ensures that subsequent requests are not tampered with.

The 3 Types of WAFs

Web application and API firewalls generally come in three models: negative, positive, and hybrid:

  • The negative security model uses simple signatures and is pre-loaded with known attacks that will block a request if there is a match. Think of this as a “deny list.” In other words, the default action is “allow” unless it finds a match.
  • The positive security model is pre-loaded with a pattern of known “good” behavior. It compares requests against this list and will only allow the request through if it finds a match. Everything else gets blocked. This would be considered an “allow list.” In this case, the default action is “block” unless it finds a match. The positive security model is considered much more secure than the negative security model — and it can block zero-day attacks.
  • The hybrid security model uses signatures as a first pass and then processes the request to see if it matches the allow list. You would be correct to ask, “Since an attack would not be on the allow list, why use an allow list?” The reason why is that less processing is required with the negative security model that uses signatures to block requests vs. processing everything through the positive security model. More processing equates to larger WAF appliances or to higher costs for cloud-based hosting.

All three WAF security models have one thing in common: They examine the inbound request and look for threats. The effectiveness of request-side examination depends on what the WAFs are looking for and how granularly they inspect the request payload.

How Attackers Take Advantage of WAF Limitations and IT’s Lack of Due Diligence

Attackers are aware that looking for attacks in traffic is computationally expensive for most organizations, and that commercial inspection solutions are designed to match real-world use cases as efficiently as possible. They know that real-world HTTP(S) GET or POST requests are usually only a few hundred bytes, maybe 1-2 kilobytes with some big cookies.

And attackers know that many WAF solutions will only scan a small, finite quantity of bytes for a request when looking for that Bad Thing. If WAFs don’t find it there, or if the request is bigger than 8 kilobytes as per NetScaler’s testing, many WAFs will not scan the request. They will consider it an anomaly and simply forward it on. I’ll say that again: Many WAFs simply forward the request with no blocking and no logging.


The WAF ‘Hack’ Explained

To bypass WAFs, attackers leverage SQL injection or cross-site scripting and pad out the request with garbage to get it past the 8-kilobyte size and then hit send. Padding a request can be as simple as adding a huge header or cookie or other POST body text in the case of a login form. The request is not scanned and is passed through to the backend server where the payload is executed.

Some WAFs can be configured to counter padded attacks, but this protection is not turned on by default. Speculating as to why this is so, I can only arrive at the conclusion that turning on such protection requires extra processing, which drives up costs for WAF users. Not wanting their WAFs to be perceived as more expensive than their competitors, vendors leave additional protections disabled. Be aware that your web applications and APIs are fully exposed if you don’t change the default setting.

A single-pass WAF architecture that is available with a WAF solution like NetScaler performs miles better than traditional proxy strategies, which is why NetScaler can enable the protections against padded attacks out of the box without the added costs.

Are These WAF Vulnerabilities New?

Padded attacks are not new, and WAF vendors are well aware of the issue. But the WAF industry as a whole has not addressed the need for the most effective protection to be turned on by default.

Some analysts have communicated this gap in security with the vendors in question, with the vendor responses being along the lines of, “This is a known and documented limitation, and customers should apply this specific rule if they want this protection.” But the workaround is often buried in the nuts and bolts of the WAF configuration guide, and admins and deployment operators can (and do!) miss it.

In today’s world, where things need to “just work” when turned on and where there is the expectation that every solution used by IT will simplify tasks and reduce administrative overhead, WAFs need to be secured from the start. Sure, if a legitimate request needs to be bigger, then it will be blocked. That’s where exceptions can be made, and admins are aware of the risk when they do so. But leaving an entire site exposed should never be a consideration.

Attackers know that many WAFs do not have protections turned on by default, which is why they take advantage of this vulnerability with padded attacks. A couple of the WAFs that NetScaler tested were not vulnerable to this attack method, but many were. Some WAFs had slightly larger request limits (128 kilobytes) but were just as easy to bypass once the body was padded out. Some solutions favor this “fail open” approach to avoid additional costs resulting from extra processing, to prevent unexpected false negatives, and to allow for a more simplified — though less secure — setup.

However, the “fail open” approach violates the “strong defaults” principle of cybersecurity that we should expect from security vendors. When choosing a WAF, you need to ensure that you are protected out of the box against padded attacks.

The Takeaway: 3 Simple Steps to Securing Your WAF

Your WAF solution may not be correctly configured, leaving your web applications and APIs completely exposed to attackers who can easily deploy padded attacks via SQL injection and cross-site scripting.

As you race off to check your WAF configuration, here are your three must-dos:

  • Test your web applications (both internal and external) with padded requests.
  • Examine web application logs for large request sizes where they are not expected: For example, look at a login POST form that typically contains just a username and password and ranges in size from approximately 20 to 300 bytes. If you see POST requests that are greater than 8 kilobytes in size, then this may be a padded attack attempt.
  • Evaluate whether you can make a configuration change that will mitigate padded attacks and, if you can, make sure to compare the before-and-after costs so that you get an accurate cost for the added protection.

By following this simple guidance, you can correctly configure your WAF to improve the security of your web applications and APIs.

Group Created with Sketch.
TNS owner Insight Partners is an investor in: Pragma.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.