What are the pitfalls of using the Web Application Firewall (WAF) for a Web Application Vulnerability Assessment (WAVA)?

Before doing a penetration test on our customers' web applications, a kick-off meeting is cheduled to speak about that pentest and get some information regarding the needs of the customer. One of our question is: Will the test be made with or without the WAF?

In some cases, there is no WAF ➡️ Problem solved; the test will be made without the WAF. However, when a WAF is available, we should know if this one will be in blocking mode or if the consultant will be whitelisted. That question could raise some issues, but finally the best response for most of the cases is: Without the WAF. Valentin Giannini, Cybersecurity Pentest Expert at Thales, will explain why.

What's the WAF?

A WAF, for Web Application Firewall, is a security device in front of the application which blocks some payload that an attacker can send to the web application. To put it in simple terms, the WAF protects from the injection flaws, like SQL injection, Cross Site Scripting, command execution, path traversal, etc.

That device is wonderful, because in case of a missing input validation on the application side, the WAF blocks the payload to avoid the exploitation and prevent the attacker from going deeper.

However, there are some important points to think about when a WAF is used in fornt of our application...

Physical WAF bypass

Some companies use cloud-based WAF. The use of that kind of WAF is the same as a CDN, just with security rules on it. Thus, the domain linked to the application points to the IP of the cloud-based WAF and then the WAF sends the requests to the web application hosted on premises, for example. However, that web application should be accessible from the internet, everybody can access the website by hardcoding the domain/IP on their computer. In this kind of use of cloud-based WAF, the web applicaton should be only accessible from the WAF IP and not from all the internet.

Another kind of bypass could be to simply use the web application from the internal network. Generally, the WAF is only set up for users coming from the Internet, but if the user comes from the same network, the WAF will not be used. This is a scenario that should be considered. The prerequisites for the attacker are higher, but it is still possible.

That kind of bypass could also be made by another application. For example, an application not protected by a WAF can perform some requests to another which is protected by the WAF only for the external user. Thus, a kind of pivot could be made via that application not protected by a WAF (or badly protected).

Logical WAF bypass

Another threat of the WAF is the WAF itself. If some exploits or bypasses are found, the attackers can use them and reach the web application without filtering.

The bypass could be made by encoding the payload in a certain format. that encoding could be to URL encode twice or more, to use Unicode characters, or even to use some specificities of the targeted language. For the last example, in case of SQL injection, the WAF could detect some sentences like “SELECT * FROM XXX” but some SQL language accepts comments like that: “SELE/**/CT/**/*/**/FR/**/OM/**/XXX”. So by adding “/*” and “*/” which are interpreted as comments by the DBMS, for it the sentence will be the same, except that in the second case the WAF cannot see the keywords “SELECT” and “FROM”.

In addition, the usafe of some headers like X-Forwarded-For or X-Forwarded-Host could also work to bypass the WAF. For example, by setting an internal IP or a localhost IP.

The learning and blocking modes

Most of the WAFs possess a learning mode. That mode should be enabled before going live, and the testers should use all the features to simulate each of the actions that a real user can do. When the learning is enough, the WAF is put into blocking mode, and if the WAF sees a request that doesn't look legit, as it was never seen during the learning tests, the request is blocked, and the attack is avoided.

But all that security depends on the learning mode and the tests made during that period. For instance, if the tester used special characters on some fields, such as the comment field, the WAF will learn these special characters, and they will be accepted. However, they could be part of a payload, if this one did not match the signatures... it could work, and the application could be hacked.

Another point is to be sure that the learning mode is disabled when a pentest occurs. If not, this one will learn the payload used by the attacker, and the list of allowed input could be ruined.

One final point, but not the least, the learning mode should not be let into an Internet-facing application, as there are a lot of scanners running, all these requests ruin the allowed inputs.

WAF Management

If the WAF is well configured, with the perfect match of the wanted input, it could be imagined that some management of the WAF fails.

First, if the brand of the WAF needs to be changed, all the rules need to be translated to the new one, that requires some tests in learning mode. Therefore, if you have applications to migrate behind another one, the need for human resources could be huge. That implies that some tests will not be done, or some rules will be too permissive or missing, for example.

Another possible issue is that you forgot to renew the licence. For certain types of WAF, it can continue to block the known patterns, but this one will not receive new signature patterns. Therefore, the new payload will not be detected, and an attacker could be able to use a new bypass, for example.

The life cycle of the WAF rules should also be considered as an important point. If an application changes some input, adds some pages or removes some, the rules need to be updated to limit the attack surface. If some rules are too permissive, even if the application did not require it, the risk level grows.

Come back to the WAVA

For Thales, the Web pentest called WAVA is mainly to test the application itself and not the infrastructure. The WAVA is focused on the features implemented by the application, and the consultant will try to use the right exploit for the technology used. The WAF bypass does not fit in this project mindset, as it should be considered as another type of competence.

After a WAVA, the consultant should be able to say, "the SQL query that allows retrieving the list of users is vulnerable to an SQL injection." The recommendation will be adapted to that context. With a WAF blocking some effects of the injection, the consultant could only be able to say “That feature is potentially vulnerable,” or, in the worst case-scenario, “Didn’t find the issue.”

So, with or without the WAF?

From an application security point of view, the best response should be without the WAF.

Ordinarily, the pentester should be able to assess all the features of the application and each user input without restrictions. If there is an injection flaw, this one will be detected more easily than with the WAF.

After that, if an issue is found, a test could be done quickly with the WAF enabled to check if the customer is protected during the time lapse that the developer team or the vendor needs to fix the issue.

Finally, a test of the WAF should also be made to be sure that the blocking mode is enabled, that the WAF blocks the most common payload and blocks requests that don’t fit the format of a legit request, and also to check if some alerts are raised if an IP triggers too many alerts.

Verdict?

In our opinion this initiative is good, as it takes a great concept like security.txt and pushes it even further. Everyone knows DNS, everyone uses DNS, and everyone does DNS. The lack of global implementation should not be discouraging, as long as the idea is good, and it is. So why not be one of the first ones to implement it?