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 at NetScaler, 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.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 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.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.Web application and API firewalls generally come in three models: negative, positive, and hybrid: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.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.Wow.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.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.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:By following this simple guidance, you can correctly configure your WAF to improve the security of your web applications and APIs.Community created roadmaps, articles, resources and journeys fordevelopers to help you choose your path and grow in your career.