A Web Application Firewall, or simply WAF filters HTTP traffic between the internet and the web application, and so can help protect the web app from various web application attacks like cross-site-scripting (XSS), SQL injection, and file inclusion attack, among other threats. However, it is important to note that although WAF is pretty versatile, it is not designed to defend against all types of attacks but only to various application level (OSI layer 7) attacks. A Web Application Firewall can be treated as a reverse-proxy, forcing clients to pass through the WAF before reaching the webserver to protect it.
Here, we will discuss all you need to know about WAF, starting from how it works.
How A Web Application Firewall Works
A WAF operates through a set of policies (essentially, rules). These policies are designed to filter out malicious traffic to protect vulnerabilities in the web application. A WAF is now a very popular web app protection due to its versatility and ease of implementation: we can easily modify different policies to suit our needs, allowing a faster response for different attacks.
Like other types of firewalls, the main function of a web application firewall is to filter incoming traffic. A WAF can be a hardware device, a software program, or both. WAF software is often available as a plugin or inline web server.
A WAF’s basic function is to analyze the GET and POST requests from both HTTP and HTTPS. Then, the WAF would apply the firewall policies (rules) to filter out malicious traffic. As an application firewall, the WAF analyzes both the header and the content of packets. This is also part of the reason why WAF is so effective in filtering out malicious traffic at the web application level.
In practice, we can combine WAF with other web application security software and services, for example by sending a CAPTCHA challenge when the WAF suspects a bot activity. This approach can help minimize false positives and ensure optimal user experience.
In general, a web application firewall can be configured according to three basic models. A web application might prefer one model over the other depending on its objective and use case. These models are:
As the name suggests, this model allows all traffic except those coming from sources that are included in the blacklist. The blacklist can be a specific set of policies to determine whether a source is malicious or a list of sources that are clearly malicious.
For example, there might be a policy saying that 1 IP address can only perform 100 requests per minute, so when an IP address performs 101 requests before a minute is up, it is now blacklisted.
Blacklisting WAF is typically great in public websites (and web apps) that normally get a lot of legitimate traffic from new and unfamiliar sources (i.e. a website for consumer products).
The reverse of the blacklisting model, this model only allows traffic that meets the requirement of the policies. A common approach is to only allow requests from a specific range of IP addresses.
The weakness of the whitelisting model is obvious: it can end up blocking a lot of legitimate traffic. However, it is at the same time, much more secure than the blacklisting approach. Whitelisting is better for services that are designed to be used only by a limited number of users (i.e. members-only website, internal website, etc. ).
As the name suggests, a combination of both whitelisting and blacklisting, done by implementing a set of policies and configurations to create a comprehensive whitelist and blacklist. When done properly, this is often the best approach as it can meet the exact requirement of the website.
What Can The WAFs Protect Against?
The Web Application Firewall is designed to protect your web application from various web application attacks, including:
. XSS (Cross-Site-Scripting) Attack:
the attacker inserts malicious code into an input field of the web app
. Cookie Poisoning:
the attacker alters parameter values in cookies. This can corrupt data transmitted between web pages and to the database server
. Field Manipulation:
the hacker can rewrite the code of the web app, altering values in hidden files to inject certain instructions.
. Parameter Tampering:
altering values in parameters
layer-7 (application level) DDoS attack is designed to slow down or completely shut down the webserver by using vulnerabilities in the web app to allow recursive activity
. Data Scraping:
automated extraction of data from the web pages
. SQL Injections:
SQL queries inserted in user authentication fields
infiltrating the debug option of the website to allow access to the processor
What To Look For in a Web Application Firewall
In choosing between different WAFs, here are some of the most important considerations:
Pretty obvious, how fast (and how effective) the WAF can identify and act against various attack vectors.
Due to the highly evolving nature of the web application attacks, we should be able to customize the policies of the WAF based on the unique context and needs of the business.
Unlike general-purpose firewalls, it’s important for a WAF implementation to fit itself with the web application. Different web applications might have different needs, and users must be able to update policies on a regular basis. How easy it is to manage the WAF is a very important factor to consider.
Different WAFs might use different technologies in identifying and blocking incoming traffic and flag requests based on the use case of the web application.
While a WAF is quite effective in using a policies-based approach to filter traffic, it might not be enough with today’s sophisticated cybersecurity threats utilizing 4th-generation bots. This is where pairing the WAF with a purpose-built bot detection solution like DataDome is necessary to keep up with the ever-evolving malicious bots and new threats.
A behavioral-based bot detection solution can use machine learning to better identify threats and bot-based attacks, and protect your web application from incoming threats. On the other hand, the WAF can use the rule-based approach to filter out obviously malicious traffic before it reaches the bot detection solution, creating a much more effective web application security measure.