In my experience, most organizations are prepared to discuss the scope of penetration tests when preparing for an External or Internal Penetration Test, but when it comes time to discuss specifics about a web application assessment, there’s often some confusion. One particular area of confusion is whether or not a web application firewall (WAF), or intrusion prevention system (IPS) is in place and if it would be possible to test without it in place for a specific IP address.
When asked if a WAF is in place, a fair number of clients will say they don’t know. So, let’s clear up that up first. A WAF inspects the content of web traffic for potentially malicious requests and drops them before they get to a web server. This is different from a traditional network firewall that primarily works on different levels of the protocol stack and can’t inspect the raw http contents of a packet outside of the packet header. In short, a WAF will see when someone attempts to issue a login request with the username of ' or '1' = '1'-- and drop the request, but a firewall will let the request through.
Now that that’s cleared up, some may think testing without the WAF is cheating, but the reality is, security assessments are only allotted so much time. Performing a portion of testing with some defenses disabled helps get better coverage of the application and helps identify if some of the application’s natural defenses, such as input and output encoding, are effectively utilized. In the event that a flaw such as XSS or SQLi is discovered, it’s fairly trivial for the person performing the assessment to change to an IP address that has not been allowlisted to see if the WAF properly defends against the attack or not. Unless the goal of the assessment is to gain an overall picture of the deployment environment, the primary goal of an application assessment should be to test the application and not just the security control in front of it. Another way to think of it is that allowlisting an IP address through a WAF is the most economical strategy for an assessment because the application’s inherent defenses are tested in an efficient manner, then the security appliance is tested to see how effective it is at blocking attacks.
Much like any other technology, WAFs are far from perfect, and bypasses are discovered fairly frequently. After a quick GitHub search, hundreds of resources, including automated tooling to attempt WAF bypasses, are presented. One particular technique that I have been getting a lot of mileage out of is essentially a buffer overflow that fills up the WAF’s ability to check the request. The WAF only sees junk data at the start of a request and then passes the request to the web server. The web server ignores the junk data and processes the malicious payload. This should further drive home the fact that testing without a WAF in place is a worthwhile endeavor since the WAF may have some security gaps of its own and applying a bypass to each request can cost a lot of valuable time during an assessment.
Even though it may be possible to bypass a WAF, I still feel like a WAF is a worthwhile addition to the security posture of an application environment. Note that I said “addition” because it should be part of a defense-in-depth approach to application security. It should not be used as a patch to try and cover up underlying issues with the application’s code. Technology is forever changing, and new issues are constantly being uncovered. Because of this undeniable fact, no single piece of the security puzzle should solely be relied on to protect the application and its users from attacks.