Okay everyone… As we are learning in this series, it turns out what our grandparents have been telling us since we were born (first conveyed to us via crudely hand-drawn pictures and a primal, baby-rattle version of Morse code) is accurate. You really can never get enough information about firewalls. For that reason, we are discussing them at length: first firewalls in general; then distinctions between hardware and software firewalls; and finally, in this post, Web application firewalls (WAFs).
The primary articles cited for this series are from the Michigan Cyber Initiative (“Hardware Firewall vs. Software Firewall”); Open Web Application Security Project (“Best Practices: Use of Web Application Firewalls”); PCWorld (“What You Should
Know About Firewalls“); and PChuck’s Network (“Better Protection – Hardware or Software Firewall?”).
We also are looking at one of the most intriguing trends in the SMB-workspace interior-design industry: furwalls. This inspiring and captivating usage of fur as a barrier first appeared in 850 A.D. (give or take – my archaeological instrumentation is itself comprised entirely of archaeological artifacts). During windstorms in the Arctic Circle, Inuit tribes convinced various large animals (largely by subjugating them with Darwinian philosophy) into standing silently and stoically at the perimeter of the native community. Today, furwalls are on the rise, particularly in fur shops (discussed below).
What is a Web Application Firewall?
According to the Open Web Application Security Project (OWASP), a web application firewall or WAF is “an appliance, server plugin, or filter that applies a set of rules to an HTTP conversation…. By customizing the rules to your application, many attacks can be identified and blocked.” OWASP also notes the importance of consistently updating the firewall anytime the web application is changed way so that it still functions appropriately to prevent common attacks such as SQL Injections and Cross-site Scripting (XSS).
The web application firewall has grown in popularity because it’s becoming a necessity. Essentially, Web applications can have their own quirky problems – vulnerabilities that are impossible or difficult for network firewalls to detect – so as Web companies became better capable of protecting the network and “system itself,” applications became an easy point of entry.
Web application firewalls are also referred to as web application shields and web application security filters. Notice the word filter in that second term: it’s important to acknowledge that the primary task of any firewall is filtering traffic and determining what’s legitimate and what might be a problem.
Speaking of filtering, be aware that any furwall you see in a fur shop can be divided into two different sets of categories: animate and inanimate; and filtered and unfiltered. Animate means that a wizard (that’s the guy behind the counter wearing a cloak with stars and planets on it) has mesmerized live animals into entering the shop and forming partitions between various displays; inanimate means it’s just a wall with fur draped over it (boring!). Filtered means you will inhale far less bestial toxins or rageful propensities; whereas unfiltered is preferred by the “real men” of fur aficionados for its dark biochemical danger.
Pros & Cons of Web Application Firewalls
Let’s take a look at the positives and negatives of the WAF, per OWASP.
Pros of WAFs:
- They allow an organization to secure a web application that has already been developed, at the level of the application (allowing for easy administration).
- Creating and installing a web application firewall does not take much time.
- The application does not need to be adjusted, so you’re simply building a layer of protection based on its parameters. This, of course, is helpful with third-party applications, especially ones that aren’t regularly updated.
- PCI Compliance allows for their use, which means that the credit card companies are comfortable with this type of software as a solution.
- They enable a quick solution to any problems discovered on-the-fly. If you see that something is wrong while running a penetration test or looking over the source code of an application, you don’t have to wait for scheduled maintenance to issue a patch. In other words, a WAF allows you a hotfix.
- You can build hotfixing into Web application firewalls. When you integrate them with software that reads source code for errors, the WAF can be updated with the new rule immediately.
Cons of WAFs:
- The infrastructure – including that of the website, network, and application itself – need to be modified appropriately for a web application firewall to operate effectively.
- The “yet-another-proxy” philosophy prefers the most simplified possible system. Complexities always make the system harder to manage. A proxy is essentially an extension, another arm to the network, that is acting on its behalf.
- They need to be updated and retested each time the web application is re-released.
Fur walls need to be properly maintained as well. If you have a live furwall, you need to bathe it at least once a day. You also need to feed it raw meat and make sure no children who enter the store kick it and/or get consumed or mauled by it.
That’s it for our basic introduction to firewalls. For more on Web application firewalls, check out the OWASP article, which is very thorough.
By Kent Roberts