Here’s why:
1: If they aren’t whitelisted, a penetration tester is really testing your WAF
There’s nothing wrong with having your WAF tested. After all, you need to know if it’s doing its job properly by testing its configurations, policies, and deployment however, a WAF test is not the same thing as a penetration test. The things a tester needs to do to fully test your WAF are not necessarily the same as what they’ll do to bypass your WAF to attack a specific application.
So, by all means, have your WAF tested — but keep it as a separate exercise to penetration testing your applications.
2: Penetration tests are typically billed by the hour
Bypassing a strong WAF is not trivial. It takes time. And, as noted above, penetration tests are billed by the hour or purchased in blocks of hours. Simply put, if your penetration tester has to spend time evading your WAF, it will take longer — and cost more — to complete a thorough test.
3: Penetration tests are conducted under time constraints — cyberattacks aren’t
In most cases, penetration testing is conducted over an agreed number of hours or defined level of effort which equates to a specific investment. Evading your WAF may be a slow process, leaving insufficient time to test the actual application — particularly if the engagement hours are low or restricted due to budget constraints.
At MegaplanIT, our penetration testing engagements last a minimum of 60 – 80 hours, with longer tests running as high as 160 – 300+ hours. For a high-value target, attackers may be willing to spend much longer than this to find and exploit a vulnerability. If you want your application to have a chance of withstanding serious, prolonged attacks, you need maximum efficiency from your penetration test investments.
Keep in mind that “high-value” targets are subjective. An application that may seem of minor importance to you could be very valuable to an attacker. This is particularly likely if it’s hosted on the same server as other applications, as compromising one application may allow access to the others.
4: Real vulnerabilities could be missed without whitelisting
The most important reason why it’s important to whitelist penetration testers is simple: If you don’t, there’s every chance a serious vulnerability will be missed.
Your penetration tester might take a long time to evade your WAF, or may not be able to evade it at all. In either case, when the engagement comes to an end you won’t know about real vulnerabilities that have been missed.
Of course, this begs another question:
If the WAF prevents the tester from finding or exploiting a vulnerability, does it really matter?
Well Not Exactly….
When a WAF prevents penetration testers from thoroughly testing an application — and causes them to miss real vulnerabilities — the customer organization misses the opportunity to find out about the root causes of vulnerabilities.
For example, maybe the organization’s app developers are using insecure coding practices. This is actually very common because most developers aren’t security experts. And if the organization doesn’t know that, because vulnerabilities aren’t being uncovered, those developers will keep on coding insecurely.
And that’s not the only reason why organizations shouldn’t rely exclusively on their WAF to protect web applications.
WAFs Are Great… But Not Perfect
Let’s be clear about one thing: WAFs are not infallible.
If they were, nobody would need to worry about penetration testing. They would simply implement a WAF and tick application security off of their to-do list. To understand why that would be a bad idea, you need some basic knowledge of what WAFs actually do.
Fundamentally, WAFs work in one of three ways:
Blacklist
Allows any traffic to pass through unless it has been specifically banned. Blacklist WAFs are often cloud-based, are very easy to set up, and require minimal maintenance. For these reasons, they are by far the most popular choice. They are also the easiest WAFs to bypass.
Whitelists
block all traffic unless it has been specifically allowed. WAFs that use whitelists are more secure than blacklists, but are hard to set up and require a significant amount of ongoing tuning and maintenance.
Combination
WAFs that combine both blacklists and whitelists are, unsurprisingly, the most secure option — but they are also the most expensive, hardest to maintain, and most likely to accidentally block legitimate traffic.
Since blacklist WAFs are by far the most popular option
Here’s a high-level overview of some of the many ways they can be circumvented:
Encoding Requests
Since most WAFs rely on blacklists to identify and block malicious requests, one technique attackers can use is to encode their requests. While far from a sure thing, this simple technique is sometimes enough to bypass a WAF.
Attack payload obfuscation
Again, most WAFs are set up to block payloads that are known to be malicious. But if those payloads are slightly altered they may slip by unnoticed.
New or missed payloads
Any malicious payloads or requests are not yet included in the WAF blacklist (or have been missed accidentally) will be treated as legitimate traffic.
Large requests
Strange as it may sound, many WAFs ignore very large requests because not doing so would cause significant performance issues.
Finding exceptions
Many WAFs are set up with exceptions to their normal ruleset to prevent known issues. For example, if a WAF has been erroneously blocking traffic from a certain type of device, it may be configured to accept everything from those devices to ensure legitimate traffic isn’t blocked. Attackers have various techniques at their disposal to track down these exceptions and may be able to exploit them once identified.
Taking over legitimate accounts
One of the most common tactics used to breach a target network is to take over a genuine user account. This can be done via “credential stuffing” (automatically trying millions of credential combinations until a hit is found) or by tricking a user into giving up their credentials. Either way, once an attacker has access to a genuine account, they can continue the rest of their activities freely without needing to manually evade the WAF.
To Summarize
As valuable as a WAF is for application security, it’s far from a perfect solution. And while it’s admittedly more difficult to circumvent whitelist and combination WAFs, it can still be done in a variety of ways. In fact, there are literally thousands of articles and video guides created by security experts and hackers that teach would-be attackers (and pentesters) how to bypass different types of WAF.
And it’s not always the fault of the WAF itself when things go wrong.
WAFs can go down. They can be misconfigured. Any number of technical issues that aren’t directly related to the WAF itself can prevent it from functioning properly. And when that happens, it’s important to know that your web applications are resistant to cyberattack.
Feeling a bit less certain about the security of your organization’s assets? That’s a good thing. Once you recognize that putting a WAF in front of your web applications doesn’t completely solve the problem of security, other measures — including penetration testing — become a higher priority.
The Best Compromise = DO BOTH!
There are plenty of reasons why it’s a good idea to whitelist penetration testers on your WAF. But that doesn’t mean there’s no value in finding out whether identified vulnerabilities can be exploited without the tester being whitelisted.
One excellent approach is to have your testers spend the majority of the engagement checking for vulnerabilities while whitelisted. Then, towards the end of the engagement, you can revoke their whitelist privileges to see if they can still exploit any identified vulnerabilities while evading the WAF.
If the testers are able to exploit identified vulnerabilities while evading the WAF, fixing those vulnerabilities should be a very high priority. If they can’t, it’s still important to fix them, but you can take some comfort in knowing your WAF is working as intended — at least for now.
