As cybersecurity issues increase, Web application filters and Web Application Firewalls are becoming more popular. These tools can be an excellent first step towards securing your applications. How do they work? What is the difference between them? Please read the following lines for an introduction of this topic.
Filters or WAF: Who’s who?
The first kind of defense is called “Filtering”. Whether implemented as part of a development framework or implemented by the developer himself, filtering is in the end part of the application.
Of course the efficiency of this protection will depend on the awareness of the developers on security and also on their experience in developing secure applications.
The second type of defense is called WAF (Web Application Firewall). This type of product is not to be confused with “usual firewalls”, in the sense that web application firewalls analyse the web traffic and don’t stop at filtering traffic based on a particular port number, address or protocol.
Web application firewalls can be implemented on the web server itself, or in front of the web server (between the end-user and the web server).
Web application filters
A filter can be implemented by developers with a simple set of regex rules. Developers write these regex to filter data that comes to the application, in order to check whether or not the content fits what is expected (type of data e.g. string, integer, email syntax…).
However writing perfect regex rules requires some time and experience. As a consequence, developers usually copy/paste regex examples from their favorite development forum or from whatever site they find. The quality of the filtering “layer” can be very good, but usually contains flaws.
Using a library is something a lot of developers tend to choose as a filtering solution, and there are many benefits to it:
First, libraries are (usually) not the work of a single developer. It means that the team and community around the library merge all their skills and knowledge to develop something strong.
Second benefit: good libraries are maintained, which is not necessarily the case for home-made filters.
We can also add the fact libraries centralise the features, when developers sometimes implement filters themselves in different locations inside their app.
OWASP’s ESAPI or Respect’s Validation (validation engine) are good examples of such libraries.
Some development frameworks also implement their own filters.
As an example, Microsoft .Net has its own request validation feature. This filter mainly looks for HTML or Javascript in query strings, posted data and cookies, in order to prevent simple XSS attacks.
Regardless of the type of filter, this kind of protection is usually based on patterns, regex, blacklisting and/or whitelisting.
Web Application Firewalls
A WAF is in-line and monitors the web traffic, before it reaches the web application.
The objective of a web application firewall is to detect and block known attacks, like XSS, SQL injections, session hijacking, brute force attacks, etc.
Although different deployment options are available on the market, we can schematize the WAF like this:
Depending on the technology, a WAF will use different kinds of detection methods: regex, blacklisting, whitelisting, signatures, etc.
From a configuration point of view, a web application firewall can operate in different modes: logging or blocking.
In the logging mode, suspicious requests will be logged but not blocked. This kind of configuration is usually adopted when installing the firewall, in order to avoid false positives and accidentally blocking legitimate traffic!
In the blocking mode, detected attacks are blocked and malicious traffic does not reach the web server at all.
Example of an open source Web Application Firewall: mod security (https://www.modsecurity.org/).
WAFs can be installed on a stand-alone device, as a software on the web server, but can also be a cloud service.
Filters vs. WAF: which one is better?
By design, filtering is part of the application, meaning that the web application is protecting itself by preventing malicious requests from being successful.
A filter can be very specific and handle every bit of data independently, for instance to accept only positive integers where a positive integer is expected.
The downside is that making this filter evolve can be difficult. Applying updates to the filtering system implies updating the application itself.
Moreover, a filter will consume web server resources.
Web application firewalls are by design a separate feature, meaning that they can be maintained and updated without updating the application.
Since a firewall is quite often provided by a third party company, specialized in web security, we can assume it is a better protection, generally broader in terms of protection, but more generic.
It is also worth noting that third-party managed firewalls can be updated quickly to catch recently discovered attacks or vulnerabilities, which is a great benefit.
So, is one better than the other? Actually they are very complementary.
Filters and WAF: are these enough for securing a web application?
Of course, web application firewalls and filters add a strong security layer to web applications. But still, big companies are being attacked successfully despite these protections. This means that such defenses are an additional layer we add to security but that we cannot fully rely on them. In fact, Web application firewalls and filters are a safety net, nothing more.
Filters and WAFs both have bypass methods, allowing experimented attackers to circumvent protections and hack vulnerable applications. Better to pay attention to the code of the application, in addition to using filters and web application firewalls.