WAF or not WAF? Give me two! We solve the issue of web application protection
Hello everyone. My name is Askar Dobryakov, I am a leading expert in the field of business application protection. I have been involved in information security for over 15 years, three of which have been in web application protection. During this time, I have often encountered ambiguous attitudes of my colleagues towards Web Application Firewall. In the information security community, opinions regarding web application protection using superimposed means range from “simply necessary” to “an inappropriate waste of resources, it is quite possible to get by with the application’s built-in means”.
Who is right? What is the use of WAF, and what are its disadvantages? Let's figure it out. I warn you: the topic is not simple, but felix, qui potuti rerum cogoscere causas.
WAF (Web Application Firewall) is a firewall for web applications. Its main task is to filter traffic, detect and block attacks.
We, K2 Cybersecurity, are a system integrator and have completed many projects in the information security area, including implementing foreign and domestic WAFs. I have noticed that all companies approach their use in their own way. Everyone has their own assessment scale: how much WAF is needed, what functions to use and whether other means of protection should be applied.
Of course, everyone understands that web applications need to be protected. There is a whole zoo of threats, the same OWASP Top 10. The question is how exactly to provide protection – with the resources of the application itself, or with the help of an external firewall. After all, WAF is a paid solution, and its selection, installation and operation require resources and skills.
So, is the game worth the candle?
To understand this issue, let's look at the main groups of functions that are usually assigned to a web application firewall:
1. Publishing applications
First of all, WAF is assigned the functions of an external secure gateway – this follows from the solution architecture. That is, a request from the Internet comes to WAF, is analyzed, and, if everything is in order, is forwarded to the protected application. If WAF finds signs of an attack or policy violations, it blocks the request and sounds the alarm.
Since all requests in such an architecture go through a reverse proxy, the WAF must perform Application Publishing Features:
Perform balancing between backends if the application runs on multiple nodes. WAF checks the nodes for functionality, analyzes application responses for stop words (error, maintenance) and switches to working nodes if necessary.
Being responsible for fault tolerance is a logical consequence of the balancing function.
Manage SSL policies so that SSLlabs gives you an A+ rating while still allowing your clients to connect.
Manage headers, including Strict Transport Security and Cross-origin.
As a result, we get a full-fledged publishing infrastructure based on Web Application Firewall. This approach is typical for foreign solutions, for example, F5 Big-ip and Citrix. They grew out of balancers, so these functions are basic for them, and request filtering acts as an additional module.
2. Verification of input data
WAF performs a number of important functions data verification functions:
Check user input for type mismatches, suspicious constructs, and signs of attacks.
URL and Endpoint access control for APIs, allowing you to restrict user access to application functions.
Validation of form data, JSON and XML – control of data structure, presence of external entities in XML, compliance with schemes and protocols, as well as protection against attacks on the parser.
HTTP compliance control. WAF checks the correctness of methods, application responses and their security. It also analyzes the application's response to incorrect requests, such as response codes.
Securing APIs. OWASP recently published Top 10 for API Securitybut the most obvious example is attacks on API. For example, I recall a case when it was possible to perform RCE without authorization through the administration API in a foreign vendor's product. External control of API requests helps to avoid such risks.
It is also worth mentioning the positive model of WAF operation. It allows only certain requests, URLs, parameters, data formats, file types and headers. Anything that does not comply with the rules is blocked as a potential attack. This is the classic principle of “everything that is not explicitly allowed is prohibited”.
This model is reliable, but requires careful maintenance. It can cause false positives, for example, when updating an application without notifying the WAF team.
3. Attack detection
Attack detection is the most important task of an application-level firewall. It is achieved through a combination of several analysis methods:
By signatures. WAF filters out obviously malicious requests based on pre-selected patterns. This is a popular method, but it is not ideal. For example, once, when we were implementing a WAF for one company, we saw a request in the logs “/../../somefile.txt”, and some file. Obviously, this is path traversal! It must be blocked! But only half an hour later, a customer representative called us and asked: “Allow this, our application works like this… Well, that's how it was written once…”.
Behavioural analysis and event correlation allow us to identify suspicious activity. For example, several suspicious requests from one IP or multiple requests to the login form may indicate the actions of an attacker. This also includes behavioral analysis based on machine learning.
Bot detection is also often moved to WAF. It includes CAPTCHA, reCAPTCHA, Browser Challenge and even User-Agent checks.
L7 DoS protection helps to resist logic attacks on the application, frequent requests from bots, requests to resource-intensive pages and functions. WAF can monitor and limit such activity. These functions are now also often assigned to WAFs.
Virtual patches allow you to quickly close discovered vulnerabilities until the developers release a fix. WAF is configured to block requests with characteristic signs of an exploit. Virtual patches are a temporary measure, but they are useful for quickly responding to threats.
4. Visibility and observability
These terms imply monitoring of incoming traffic, detection of suspicious actions, and their analysis. All this is necessary to understand the nature of incoming requests, the reasons for blocking or allowing them, and to respond adequately.
WAF helps:
Log suspicious actions.
Send alerts about potential attacks to SIEM so that the SOC team can take action on the event and use this data during incident response and investigation.
Create web application and API diagrams that display available pages, parameters, and transmitted data. Some solutions build an API map based on call statistics, which essentially creates a full-fledged swagger. It can be compared with what was planned and discrepancies can be identified.
Scan and recheck attacks. Most WAFs can create safe test requests to check for potential vulnerabilities, replacing suspicious payloads with safe indicators.
Analyze application responses to find vulnerabilities and potentially successful attacks.
Example from practice: a completely normal request is in progress, no signs of attacks, signatures do not work. It contains four parameters right in the query. WAF sounds the alarm: “The application response contains a database password!” SOC detects this, we start to investigate and try to restore the attack.
And indeed, if all four parameters are present in the request at the same time, then such a strange response comes. We notify the system operators, they go to the developers, and in the meantime we install a virtual patch with the condition: block requests where these four parameters are present. A few days later, the developers release a patch, and the problem disappears. It turns out that the application had such a vulnerability.
5. Trust
How confident are we in the security of the application? Was it developed by our team, a third-party contractor, or is it a well-known market solution? Or maybe we inherited it and it hasn’t been supported for 10 years? Do we need additional control over the traffic between the application and external users? How quickly can we fix a discovered vulnerability? And how do we even know about its existence?
Often the answers to these questions lead to the conclusion that additional control over traffic is needed.
This point also includes formal compliance with regulatory requirements and safety standards – using a solution that the regulator trusts.
Specific WAF application schemes
As we wrote above, all these functions can be performed by WAF or other means, depending on the architecture, infrastructure and division of responsibility areas. Now let's consider how all the described functions can be landed on specific means. Below is an example of several typical schemes, which, of course, is not exhaustive.
1. Classic scheme: Internet WAF application
In this scheme, the WAF is assigned the maximum possible set of functions: publishing the application, verifying input data, detecting attacks, ensuring visibility and trust – everything.
It may seem that app creators don’t need to worry about information security at all, but there are still some things that need to be considered. These include:
user identification;
access control;
registration of user actions (precisely within the application logic, which we, unfortunately, cannot repeat on WAF);
patches to close vulnerabilities;
fault tolerance – without a fault-tolerant application, no WAF will help.
In practice, in a two-tier WAF scheme, everything, including publication and verification, is usually the responsibility of the information security department.
Information security specialists are also responsible for additional aspects, such as data compression and setting up additional headers required for the application to work. The area of responsibility of the IT department (system operators) in this case is limited to maintaining the functionality of the application itself.
2. There can only be two WAFs better than one WAF
My favorite option 🙂 In this scheme, WAFs are located one after another in a chain, forming a multi-level protection. First, conditionally, a coarse filter, and then a fine filter.
The first layer is usually a publishing system. It performs DDoS protection, bot detection and blocking, basic signature analysis, and is responsible for interaction with the outside world.
The second level of WAF is configured taking into account the specifics of a particular application. Here, a positive model is used, taking into account the logic of the application and the structure of requests. Specific signature analysis is also carried out and virtual patches developed for a specific application are applied.
After passing both WAF levels, traffic goes to protected applications, which have their own built-in security mechanisms.
This protection scheme is justified by the differences in vendors' approaches to designing their solutions. Some are more focused on balancing and publishing applications, while others focus on the protection engine. Domestic vendors usually fall into the second category.
In such a scheme, the following division of responsibilities is often observed: the Telecom department (the department that deals with networks and interaction with the Internet) is responsible for publishing the application. The Information Security department focuses on specific protection on the second WAF node, and IT continues to support and operate the application.
It is important to note that the first WAF in this scheme does not necessarily have to be a WAF. These functions can be performed by cloud and local DDoS protection systems. This configuration with a DDoS protection device instead of a WAF is considered a classic scheme for protecting published applications.
3. WAF built into the application publishing system
In some cases, organizations already have a configured application publishing system. These can be various solutions: Nginx, Envoy, Kubernetes with an ingress controller, and so on. It turns out to be a fairly complex scheme, which can be based on the principles of Infrastructure-as-Code, and changing something in it, adding another hop or reverse proxy is very problematic.
In such situations, the optimal solution may be a WAF built directly into the application publishing system.
Such WAFs provide request verification and security functions without changing the architecture. They are usually implemented as agents that are installed on nginx or another reverse proxy.
In this scheme, the areas of responsibility of information security and IT often overlap. Publication becomes the result of their joint work. For example, in one of our cases, we added WAF agent modules for publication to nginx, and the IT department continued to administer nginx. Thus, IT was responsible for the entire technical part, and security specialists saw and made decisions only on information security events.
4. No WAF at all
There are situations when an organization can do without a WAF. This approach has a right to exist under certain conditions. It is important to understand that all the functions described above must be performed, but other means are used for this.
Let's say a company already has a reliable application publishing system. The protected application performs thorough verification of input data independently, ensuring strict input control. We quickly eliminate vulnerabilities, constantly conduct pentests, and perform vulnerability analysis. We fully trust the application, and we have no compliance requirements, or we have received a certificate of compliance. Why not?
A publishing system such as nginx allows you to configure frequency limiters to protect against DDoS attacks and other security mechanisms. Alternatively, you can use cloud protection systems. Although attack detection functionality is necessary, we accept this risk and compensate for it by working closely with vulnerabilities.
This approach has its advantages, but requires significant resources to develop and support the application, as well as a high level of maturity. It assumes built-in application security.
conclusions
To ensure application security, groups of functions can be identified that must be performed. They can be implemented in different ways: by built-in application tools, infrastructure components, or specialized information security tools.
The choice of a specific solution depends on technical capabilities, distribution of areas of responsibility and economic feasibility. There are many solutions on the market with already implemented security features, but we know teams that prefer to develop protection themselves, relying on their expertise.
WAF is not a panaceabut only a tool that allows you to quickly implement a significant part of the application's security functions. The key task is to choose the solution that best suits your specific requirements and tasks.
