As a history buff, I was delighted when my manager asked me to write a blog about WAFs! Three thousand five hundred and seventy words later I was informed that “Women in the Airforce” (US) and Women’s Auxiliary Airforce (UK) weren’t the WAFs I was supposed to write about. My manager didn’t think my next attempt, “When Acronyms Fail (WAF),” was very funny, so now you get a blog about web application firewalls (WAFs) and SecureIQLab’s upcoming cloud WAF test.
Cloud WAFs are becoming increasingly popular for a number of reasons. A typical WAF requires hardware investments and the hardware requires physical office space. Sitting on-prem consumes power, which may not seem that expensive until rogue IT staff start using it to mine bitcoins 😊
Seriously, IT departments are already taxed to capacity. Another appliance to secure, update, if even possible, and monitor. The time required to install, configure, and maintain an on-prem WAF is time that takes away from other crucial activities, such as monitoring data from SIEMs, patch management, and other related activities essential to security and the maintenance of line-of-business (LOB) applications and services.
Cloud WAF adoption is being driven by the growth of the usage of cloud computing which encompasses native cloud applications as well as the migration of applications from the data center to the cloud. Covid-19 has accelerated the growth of cloud as small brick and mortar shops were forced to conduct business on the web, and because it accelerated a growing work from home trend which has resulted in IT’s own little zombie apocalypse. Cloud providers like AWS and Azure are providing turnkey solutions that small shops cannot build in-house. At the same time Web-Application attacks are rapidly increasing in frequently and in volume., hence Cloud WAFs are becoming increasingly common in AWS, Azure, and other marketplaces.
A cloud WAF increases performance by reducing the need to monitor out-going activity from web apps, making it predominately a mono-directional service. A traditional WAF monitors all inbound and outbound activity from all users, thereby increasing latency. A cloud WAF is security as a service (SaaS) which means hardware, patching and deployment are managed by the hosting provider. Deployment is extremely scalable and a simple process. There are other advantages to Cloud WAFs *IF* a high-quality cloud WAF is used. A cloud WAF still must offer the same protections in the OWASP top ten web application security risks.
SecureIQLab is a cloud security company and as such has an obligation to assist consumers in making the most effective cloud security decisions. With that in mind, we will soon be reporting the results of our Cloud WAF testing. Are there any surprises? I don’t know. A blogger is a blabber and as such, management won’t tell me about the juicy tidbits, but we’ll both find out soon.
Firewalls vs WAFs
The primary purpose of traditional firewalls, AKA firewalls, is to protect devices from unauthorized access for both inbound and outbound traffic. If a vulnerable application exists on a device behind a firewall, the app may be protected from external attacks, depending on what ports are being attacked and how various rules are configured. Should malware with “phone home” functionality make it to the server or endpoint, then locked down ports can prevent outbound communication as well. These firewalls are essential. Anecdotally, when SQL Slammer hit, many if not most Windows XP machines could not stay connected to a network long enough to download a bug fix before they were infected again. As a result, Microsoft added a firewall to Windows XP SP2 and once again users were able to download bug fixes for everything that wasn’t euphemistically called a feature.
Without additional security measures when something gets past the firewall, applications start getting arrested for indecent exposure. Herein lies the problem with web applications. Typically, web applications are not behind a corporate firewall or protected well enough to compensate for their exposure to attackers. The security efficacy of WAFS is such that they are the recommended one of two options for PCI DSS 6.6 compliance, with web vulnerability scanners being the second and less effective option. The use of both is recommended. Bear in mind that PCI DSS is a baseline for certification.
SecureIQLab’s inaugural WAF test ensures that the WAF meets the minimum requirements to provide effective protection for the OWASP (Open Web Application Security Project) top 10 most critical risks.
The OWASP top 10 are as follows:
- Injection
Perhaps you remember the iconic XKCD code injection lesson:
Injection attacks have been around for a very long time, and even though they are now old enough to drink, their primary purpose is to drive IT professionals to drinking.
Quite frankly, if your WAF can’t protect against injection, you may as well protect your web apps with Game of Gnomes. At least when your web apps are compromised and your employer is being sued as a result of the data breach, you’ll have a nice, silly book to read. Seriously, if you can’t laugh about it, you’ll cry.
- Broken Authentication
Continuing with the OWASP top 10 we have broken authentication. To be clear, no WAF will protect you from bad passwords. We all know that passwords are broken authentication, but the broken authentication that OWASP is talking about has to do with incorrect authentication and session management configurations or implementations. If you aren’t using https, you’re making a session hijack so simple that it can be done by accident. I would know, I accidently hijacked a security researcher’s Twitter account when I was playing around with Firesheep at security conference. I tweeted a snide comment about Microsoft during the live Twitter feed. We were all surprised when it posted from his account… while he was presenting 😊 Things on the unencrypted cookie front have improved, but a lack of multi-factor authentication is still the most common authentication disaster.
- Sensitive Data Exposure
At number three on the OWASP dirty dozen minus two, is sensitive data exposure. According to Fierce Healthcare, in 2019, 41 million patient records were affected by breaches. Need I say more? No, but I will. Data in motion and at rest should be encrypted. Here’s the power of encryption. My social security number can be found in this blog. Yay steganography! It is trivial for an insider to exfiltrate data using steganography. Just in case someone is able to find my social security number in the picture, I encrypted my social security number before encoding it. That said, you can probably buy my social security number for a dollar on the dark web. Incidentally, The APT29 group is known to have used steganography to hide command and controls (C2) servers.
- XML External Entities
Moving on to number four we have XML external entities (XEE). XEEs can be used to exploit bugs in XML parsers thereby allowing an attacker to gain a foothold in a network, and/or extract sensitive data. In addition to switching to a safe protocol such as JSON, digital rights management (DRM) can add another layer of defense. Falling victim to an XEE attack can bring us back to number three – sensitive data exposure.
- Broken Access Control
Broken access control is ubiquitous and makes it to the OWASP top ten in position number five. Simply making a change to a URL is an easy way to exploit broken access control. Don’t believe me? Google ““class-snoopy.php” and you’ll find sites with broken access control. One such find looked like this:
Simply adding /wp_includes to the URL of a website will hopefully get you a 404 or unauthorized access message, but not always. I see a either a WAF or a gaffe in your future…
- Security Misconfiguration
Moving on to number six we have security misconfiguration. If I was OWASP I would probably refer to it as 666. Security misconfigurations range from unpatched systems, to error messages revealing sensitive information, such as the one above, to the use of default configurations. In the case of IoT devices, sometimes just bringing one into the office should count as a security misconfiguration! Devices such as Alexa and Echo can only be secured with a hammer or a microwave oven.
- Cross-site Scripting (XSS)
Cross-site scripting (XSS) errors hold the coveted number seven position. Like it’s cousin, injection, a lack of sanitization is one method used to instigate an XSS. At https://techbeacon.com/security/cross-site-scripting-how-go-beyond-alert/ Ken Muhl explains that XSS attacks are often not taken seriously due to the risk of being misunderstood. You know who understands the risk? Yeah, WAF vendors. You know who else understands the risk? Charming Kitten, CopyKittens, Fox Kitten, PittyTiger, and… well pretty much every APT group in the world.
- Insecure Deserialization
Insecure deserialization takes the number eight position. Serialization takes an object and turns it into a data format. As you might expect, deserialization reverse the process. When deserialization is applied to untrusted data is when the ship hits the fan (damned autocorrect). For more information on deserialization, OWASP has a cheat sheet for it and many other topics.
- Vulnerable Components
Number nine in one of those “no shit sherlock” (NSS) topics. The use of vulnerable components. This may seem obvious, but components such as DLLs often appear in multiple applications. This is especially problematic for applications that are no longer supported. A case in point. The Xiao Steganography app still works, kind of, but it hasn’t been supported for years and contains a vulnerable version of oleaut32.dll. Wait, what? You aren’t using a vulnerability assessment scanner? Guess who is? Yeah, those damned cats.
- Insufficient Monitoring/Logging
And last but not least… insufficient monitoring and logging. Many security companies report that the time to detect breaches can be over 200 days. Without sufficient logging and monitoring, the time to detect breaches is adversely impacted. Monitoring and logging are essential components of quality forensics.
11: Decaffeinated Coffee
Finally, at number eleven, we have decaf coffee. No WAF will protect you from that.
I sure hope that all of the WAFs that we test pass with flying colors, but please don’t denigrate products that may not perform so well. The folks behind the products are our allies and are fighting the good fight.
Randy Abrams
Señor Security Analyst
SecureIQLab
