If you’re reading this, the chances are that you run a web application. What do we mean by a web application? Now that websites are so responsive and feature-rich, we’re basically talking about everything on the Internet! WordPress? Web application. Joomla? Moodle? Drupal? Yep, they’re all web applications. Here’s why you need a web application firewall:
How Web Application Attacks Work
As their name suggests, web applications are exposed on the Internet for anyone who wants to use them. But this means they’re also wide open to bad actors too.
SQL Injection
That’s okay isn’t it? We have usernames and passwords to protect our applications, right. Sure, but what about when bugs are found in the code running underneath your web application? For example, some bugs allow mallicious actors to inject code into your web application and have it run. That code might reach into your back-end database and pull out all of your sensitive company information. This is called an “SQL Injection” attack.
Distributed Denial of Service (DDoS)
That’s just one example of how all of our web applications come under fire every single day. Another huge attack surface is by what’s known as a Distributed Denial of Service (or DDoS) attack. This is where infected machines all around the world get together and access your web aplication all at the same time. This can comprise many hundreds of thousands of bots all accessing your site again and again for as long as the attacker chooses. The effect being that your web application is so busy trying to serve all the bots that it can’t serve the real people trying to access your site. The attacker is denying your service to your customers.
How Web Application Firewalls Work
Now we understand what an attack looks like, how do we prevent them. The answer is in the question – we can protect against them because we know what they look like.
A Web Application Firewall inspects everything that tries to connect to your web application, and checks it against a list of things it knows is dodgy. Think of it like a doorman at the club. They’re checking everyone on the way in against a list of mugshots of the known brawlers. If your face is on the list, you’re not coming in. Similarly, if you turn up with 10,000 of your mates with the intention of not letting anyone else in the club, you guessed it, you’re not coming in.
False Possitives
There is a downside, and our doorman analogy actually covers this too. What if you look a lot like someone on the banned list? Chances are you’ll find yourself banned too. Not ideal. This can happen with web application firewalls too if they’re not configured absolutely perfectly. There is a period of tuning and refinement involved in deploying web application firewalls.
Wisdom of the Crowd
Okay, my idea of a doorman is getting a bit strained now, but basically, web application firealls have pubwatch! If you use a web application firewall as a service from one of the big players, they all report back to their vendors about attacks they have witnessed on the networks they protect. If that same attack is leveraged against your network, your web application firewall already knows about it, and won’t let it through. Cool, no?
Where Can I get a Web Application Firewall?
Great question. It depends what you’re doing and where your application is hosted. If you have a simple WordPress site like ours, you might get away with WordFence. If your application is a big bigger, you might look towards CloudFlare’s offerings.
For larger and more customised deployments, you might need to think about more customisable web application firewalls such as AWS’s WAF.
What I’m saying is there isn’t really one solution for this multi-fascited problem, but rather it needs to be tailored to your environment and what you need to protection from. Needless to say, we’re always here for help and advice whenever you need it.
