Today, web applications, or “web apps” for short, dominate the business landscape. They gather, store, and process the sensitive personal and financial data of millions of Internet users. We now spend the majority of our computing time in the cloud, accessing online services and resources, from e-mail to e-commerce, via our browser.
As information technology has evolved, so have computer hackers, who can now steal not just the identity of one person, but millions at a time. The Hypertext Transfer Protocol (HTTP), published in 1991, has tried to keep up, chiefly with the aid of Secure Sockets Layer (SSL) and Transport Layer Security (TLS). But despite these improvements, the long, complex history of HTTP provides fertile ground for HTTP desync attacks, and there remain no guardrails for application security flaws.
Website compromise and data breaches are still common, leading to the loss of revenue and customer trust, as well as lawsuits and even the extinction of many businesses. Therefore, it is essential that web app owners up their security game and invest in a Web Application Firewall (WAF).
No security product — not even VGS — is a silver bullet against every type of computer network attack. Security is about layers, and defense-in-depth. A layered approach to security allows each component to do one specific thing, and do it well. It also allows individual layers to mitigate risk from other layers, reducing negative impact if another layer is compromised.
This blog will focus on the combined power of VGS + WAF. Here, we will cover what a WAF is, how it works, basic configurations, testing, and remediation. In our next blog, we will cover WAF placement and visibility, specifically in relation to VGS products.
What is a Web Application Firewall?
Traditional firewalls sit at the network or transport layer of the OSI model, between trusted and untrusted networks. But today, you can deploy a WAF at the highest layer (the application layer), where it sits right in front of your users and data. Both types of firewalls handle access control and network defense, but in unique positions with unique tools and strategies. Working together, they offer your enterprise greater defense-in-depth.
WAFs protect your enterprise against a wide range of attacks that specifically target web apps, including remote code execution, insufficient authentication, exploits, SQL injection, cross-site scripting (XSS), cross-site request forgery (CSRF), directory traversal, file inclusion, HTTP floods, and more. Many of these attacks are detailed in the Open Web Application Security Project’s Top 10 Web Application Security Risks.
There are three different types of WAFs: network, host, and cloud. Network and host-based devices are typically located on-premises, while a cloud model is a SaaS solution. There are both commercial and non-commercial WAFs. One open-source WAF, ModSecurity, is a part of OWASP and has its own rule configuration language called “SecRules.” Commercial WAFs vary significantly in price depending on interface, options, requirements, etc. Typical costs are based on the number of rules you configure and the number of HTTP requests you receive. All things considered, we believe that most VGS customers would be best-served with a cloud-based WAF.
How does a WAF work?
A WAF intercepts and inspects inbound web requests (HTTP/HTTPS) to detect and prevent malicious traffic from reaching your web apps. WAFs are powerful and can dig deep into network packets to evaluate what is inside the payload. They can parse data, identify malicious signatures, and evaluate suspicious behavior. All of this is necessary to recognize and stop sophisticated network attacks.
A web request must adhere to your security rules, often called policies, or it does not get permission to touch your web app. As with traditional firewalls, WAFs can make decisions based on “positive” or “negative” logic. Positive security policies, such as a whitelist, typically run first and may allow only a certain type of inbound request or from a certain location (or both). Negative security policies, which usually run second, can block an inbound request that matches a malicious signature (e.g., SQL injection) or an attempted denial-of-service.
Each strategy has its strengths and weaknesses, and it is often necessary to leverage both. However, you are highly encouraged to create whitelists because they are designed to deny everything except that which is specifically allowed. They also consume less resources than a blacklist and go a long way toward preventing zero day exploits.
WAF Configuration
A WAF has three components:
-
Conditions: the characteristics of an inbound web request used for decision-making, such as source IP address, hostname, geography, time, or type of attack (e.g., XSS).
-
Rules: with boolean logic, you tell your WAF what to do, including whether to stop the request or simply alert on specific behavior.
-
Web access control list (ACL): “A B C” stands for allow, block, or count (the latter is used for rate-based rules, in which you allow a maximum number of requests matching specific criteria, and then block the rest).
WAF rule sets can quickly become long and complicated. There are many sketchy IP addresses out there and thousands of malicious signatures to consider. The attack space is constantly growing, and hackers have the incentive to innovate. With rate-based defenses, it can be difficult to stop offensive behavior without creating your own denial-of-service in the process.
In spite of these challenges, help is never too far away. Some WAF providers offer pre-built templates to get you started. The open-source ModSecurity WAF Core Rule Set covers many popular web apps and common threats, and offers a high level of security for Apache web servers. One of the strengths of a WAF is the ability to modify policies quickly; for example, in the event of a DDoS attack, rate limiting can be set to slow the barrage.
Finally, WAFs have a transparent mode and a proxy mode. In the first case, a WAF sends web requests directly to the web application. In the latter, a WAF provides additional protection to the server by acting as an intermediary hop -- which can increase security, but unfortunately also increase latency.
Testing & Remediation
Due to the size, speed, and complexity of today’s networks, security can be hard to achieve, and is always a moving target. You must continually test your WAF configuration. Vulnerability scanners and penetration testing can find software coding errors and discover unknown vulnerabilities.
Many web apps can be quite unique, with their own intrinsic vulnerabilities and exploits. Furthermore, enterprises often have numerous web apps to protect.
Positive rules are highly restrictive, but can be a challenge to create and maintain. Negative rules are often complex and voluminous, result in a high number of false positives, and still have trouble identifying every malicious web request.
Hackers engage in numerous strategies to bypass WAFs. Here are some examples:
-
Pre-processor exploitation: deceiving a WAF into skipping input validation
-
Impedance mismatch: a WAF interprets input differently than the backend
-
Rule-set bypassing: sending payloads undetectable by a WAF
Once security vulnerabilities become known, it is critical to fix them, and the sooner, the better. For some hard-to-kill bugs, it may be necessary to apply virtual patches, or immediate but temporary fixes.
Conclusion
For any modern enterprise, a WAF plays a vital role in a cloud-based defense-in-depth security strategy. Not only does it protect against malicious web traffic and hedge against web app vulnerabilities, but it also helps to fulfill information security guidelines and compliance requirements such as PCI DSS and SOC2. And as a bonus, filtering out all of that junk traffic can reduce costs and improve your customer user experience.
If you have any questions, or would like to request a demo, please contact us.
