When speaking with clients in my day job, I often hear some misunderstanding as to what exactly a WAF is, why one may be needed and how they differ in protection from a typical “Next-Generation Firewall”.
This post aims to take a high-level look at the above and clarify some of the misconceptions around WAFs that I tend to come across.
What is a WAF?
WAF stands for Web Application Firewall. As the name suggests it is security solution aimed specifically at protecting web-based applications running over HTTP(S), which in this day and age is the majority of applications you’ll come across.
WAFs aim to protect against attacks targeting misconfigured and vulnerable web-applications. These can pose risks such as those highlighted in the OWASP top 10 project. Security risks that WAFs can help to protect against include things such as:
- Injection flaws such as SQL injection
- Broken authentication and access-control functions
- Cross-site scripting (XSS)
- Form/parameter tampering
- Brute force attacks
Like most solutions in security, WAFs are not a silver bullet. They do not act as a replacement for secure-coding practices in much the same way an IPS system does not replace patching of operating systems. WAFs can be used as part of a layered approach to security to help protect against inadvertent issues.
“I’ve Got An NGFW - I Don’t Need One”
A common misconception. You’re typical NGFW does not provide you the level of protection a WAF does - they just aren’t designed to. NGFWs are designed to give you port/protocol/application-based filtering of traffic - but this will not help with most web-focussed attacks. SQL injection or XSS within a session are still valid HTTP from a firewall’s perspective. As are actions such as tampering with forms, tampering with parameters or trying to brute force logins/access resources you shouldn’t.
Perhaps you have IPS on that firewall as well - that will help you right? Yes and no. The IPS will no doubt have certain signatures that will help protect against certain web-based attacks, but they will be by no means as comprehensive as those you would find with a dedicated WAF solution. WAFs go way beyond the protection that an IPS can provide and allow for detailed whitelisting and blacklisting. This could be things such as only allowing certain values in parameters, certain lengths of URL etc.
You also have to ask yourself if your NGFW will be able to see the traffic. The majority of web traffic nowadays is encrypted in TLS sessions, and whilst modern firewalls are capable of decrypting these sessions, they often suffer from significantly reduced throughput as a result. This isn’t to say WAFs won’t have the same problem, but for appliances that are specifically designed to protect web apps they often have better performance and aren’t trying to do a myriad of other functions such as URL filtering and non-web application inspection at the same time.
Some firewall vendors will offer “WAF” protection as part of their solution, but in all honesty, these are likely to be very basic and just add more load and complexity to a firewall that is undoubtedly doing a million things already.
My Web-Apps Are Only Internally Facing
If you’re web-applications are not externally facing then yes, there will be less risk associated with them. But don’t assume that they are inherently safe just because they aren’t exposed to the Internet. This is legacy way of thinking and is why more and more organisations are transitioning to “zero-trust” (buzzword bingo anyone?!) type architectures.
A compromised endpoint in your network can give an attacker all they need to launch attacks against internal web application, which by nature of being internal often contain more sensitive data. A WAF can be an incredibly useful tool to have for both internal and external applications.
What Are Some Of The Features A WAF Provides?
WAFs will vary in functionality from vendor to vendor, but typically all WAFs will allow you to implement policy in both a blacklist (block bad traffic) and whitelist (only allow what you define as good) approach. Typically, you’ll probably find you use a mix of the two in a bit of a hybrid model - both have their pros and cons. Most WAFs will go through a period of “learning” to help identify what normal looks like for a given web-application and tuning can usually be done both automatically or manually for a more fine-grained and thorough approach.
Some of the typical things you may see a WAF doing after a period of learning include:
- Blocking of known malicious attacks using specific signatures
- Identification and blocking of XSS and CSRF requests
- Allowing only permitted file types, URLS and HTTP verbs (e.g GET and POST, but not DELETE)
- Allowing only specific lengths in parameters/URLs/Query strings etc.
- Login enforcement and attempted violation detection
- Identification and blocking of brute force/credential stuffing attempts
- Cookie hijack protection
- Denial of Service Protection
As I say, exact features will vary from vendor to vendor and some solutions add some interesting behavioural-based features and extend protections to client browsers to help protect end-users as well as just the website.
The Downsides Of WAFs
Downsides? I thought WAFs were a good thing?
They are! But they can also be complex, and resource intensive to implement/manage. WAFs are not usually “set and forget” type solutions, particularly where you take a whitelisting approach to policies. As your applications change through their lifecycle, so too must your policies.
WAFs also require input from people beyond your typical “infrastructure” teams. When tuning and implementing WAFs you will more than likely need involvement from your application developers to validate if certain things are expected or not, especially when you are talking about whitelisting approaches.
There are options to help you reduce the complexity you face, such as professional services or managed solutions - let the experts who have done it before take the hassle and guess-work away from you.
Cloud-based solutions such as those offered by the likes of Cloudflare, Akamai and AWS also offer a less-complex offering that takes a more “tickbox” type approach, but at the sacrifice of customisability, features and security efficacy. What type of solution you decide to go for will likely depend on the teams you currently have, the complexity of your applications, where they reside and what your specific requirements are.
What WAF Do You Use?
Do you currently use a WAF? If no - what are your reasons for not doing so? If you do, which vendor do you use and how do you find the solution? I’m keen to hear any opinions good or bad - all will be treated confidentially. Feel free to drop me a message on Twitter, LinkedIn or Email will have to do for now :)
2019-06-04 00:00 +0000