What’s A WAF

To put it simply, a WAF is a Web Application Firewall. It can help to fill in the security gaps which a traditional firewall can’t.

To understand more, let’s start with traditional firewalls. If you don’t work in IT, you will most likely be thinking of the Windows firewall whilst if you do work in IT, you’ll be thinking Fortinet or Palo Alto (There are more vendors).

If you’re a parent, you might also be aware of the one you can control on your broadband router:

What a traditional firewall does control the flow of traffic. To keep it very high level, lets look at the basic diagram below.

Both computers are on the same network and can speak to each other. This isn’t what you want though so you place a firewall in-between. You want to allow computer 1 to speak to computer 2 but not the other way around.

You setup a rule to allow computer 1 to speak to computer 2 and deny the rest.

The firewall can easily block this as it can inspect the traffic at the network layer. It can see computer 2 trying to speak to computer 1 and follows its rulesets. Because we’ve set it to block, it denies the traffic.

This is a very simple example though as firewall nowadays have IDS, IPS and a whole range of features that can help secure your network.

This may be leaving you thinking, so why do we need a WAF then?

Well, lets look at the OWASP top 10:

As you can see SQL Injection is at the top and so it should be. This is a massive threat that has been going on for some time. The reason why is because of poor coding/design and somewhat lack of technology (until now).

Let me explain and run through an example of how SQL Injection works. I will keep it very simple though so for you experts out there, try not to pick it apart too much.

let’s say you’ve got a security conscious person behind the wheel and he’s implemented a 3-tier model and placed firewalls in-between each role server. This should be enough to stop unauthorised access as the only service that is accessible over the internet is the web front end. This server simply makes the site available and handles requests. All the data and controls are happening at tier 2 and 3 so the web server doesn’t store anything of value.

So why does this not prevent SQL Injection?
Well because SQL injection attacks exploit weak code or vulnerable web applications. If you look at the diagram above, an attacker can’t get at the data as it’s behind several firewalls and on a private network. The attacker would have to be on the corporate or private network which those servers sit on before they could even attempt to access them. Even then, there is no guarantee that the firewall would accept the traffic. All of this would also take a lot of time and effort which may not pay off.

They may try and scan the web server since they can reach it. The problem is that none of the ports they normally attack are available such as SMB (File transfer) or RDP (Remote connection).

The only access that is available is 443 which allows them to view the site. To most, this would seem like the attacker has nowhere to go. Although that may be true for some, if they find a weakness on the actual site itself, it may be their way in.

Let’s say they find a search box which allows them to run queries against the site. Things like, find details on a user or product. This information would be stored in the database so the web server would have to pass the input text onto the application server which can query the database for the information. The application server can then return the values for the web server to display.

This seems normal and when speaking about firewalls, all would be green and allowed. The web server can speak to the application server and the application server can speak to the database.

So what if the attacker wants to use SQL injection to bypass the login? 
Well the request would be allowed through wouldn’t it. All the that firewall would see is the normal flow of traffic, just like the search box example above.

The firewall isn’t looking at the query’s the web server is passing but more the source and destination (Application Server to Database Server). This is essentially where WAF comes in.

A WAF would be able to notice that the attacker is using SQL injection and be able to prevent it. It’s able to do this as it works at the application layer. A WAF can go deeper and be able to understand what the client is asking the web server to do. If it appears to be a common attack or malicious, it has the power to stop it.

Common models see them behind a network firewall. The reason why is so that the network firewall can focus on blocking unwanted traffic such as malicious sources, whilst the WAF can focus on fighting common attacks such as SQL Injection and cross-site scripting (Xss).

WAFs are still maturing though. They do require the developers and security to work alongside each other in order to secure the application correctly. A WAF should be part of the testing and should be a factor from the beginning, otherwise you may find yourself with too many false positives and have legitimate traffic blocked.

You will also need to be aware that there are ways around them. To begin with, they have a fingerprint. This can be used to identify your WAF which in turn could allow the attackers to find a vulnerability.

These fingerprinting tools are lightweight and very effective.

WafWoof is one of the most popular out there.
Github: https://github.com/EnableSecurity/wafw00f

To install, simply run the following inside the directory:

python setup.py install

Once installed you can run:

wafwoof [site]

This can then help identify what WAF the destination has.

If it doesn’t or if wafwoof fails, it will show the following:

If you don’t want to use Wafwoof, you can use the following scripts with NMAP:

Nmap -p 80,443 –script=http-waf-detect site
Nmap -p 80,443 –script=http-waf-fingerprint site

The fact of the matter is that WAFs are not full proof. A WAF will help create a barrier that may deter attackers from targeting you but solid design/code will always be the best prevention.

If you want to know how or more, I recommend reading the following:

OWASP Bypassing WAF: https://www.owasp.org/index.php/SQL_Injection_Bypassing_WAF

SQL Injection: https://portswigger.net/web-security/sql-injection