A web application firewall (WAF) is deployed on the network edge, and inspects traffic to and from web applications. It can filter and monitor traffic to protect against attacks like SQL injection, cross site scripting (XSS) and cross-site request forgery (CSRF).
A WAF operates at network layer 7 (the application layer). While it can defend against a large range of application-layer attacks, it cannot operate on its own, and must be combined with other security tools to protect against attacks targeted at other network layers or other parts of the security environment.
Firewall is a generic term for firmware that filters incoming and outgoing traffic on a network. There are several categories within this broad definition that differ in the type of protection they provide. These include stateful inspection, packet filtering, proxy servers, and next generation firewalls (NGFW).
WAF is another type of firewall, distinguished by the way it filters data packets. WAF inspects the application layer of the network and can prevent many attacks that are invisible to other types of firewalls. For example, a SQL injection attack would not be detected by a regular firewall because it does not inspect payloads of application requests, such as SQL queries.
Unlike a traditional firewall that can block traffic from specific IP ranges, geographies, etc., WAFs let you define rules that exclude specific types of application behavior that appear to be malicious.
There are three main types of web application servers: network WAF, host-based WAF, and cloud WAF.
Typically hardware-based, can be installed locally using dedicated equipment, and can be installed as close to the field application as possible to reduce latency.
Most hardware-based WAFs let you copy rules and settings between devices, to support large scale deployments on corporate networks. The downside of a network WAF is that it requires a large upfront investment, as well as ongoing maintenance costs.
An alternative to hardware-based WAF is running the WAF as a virtual appliance, either locally, often using network function virtualization (NVF) technology, or in the public cloud, by deploying a pre-configured cloud machine image. This reduces capital expenditure, but still creates maintenance overhead.
Can be fully integrated into your application code. The benefits of this deployment model include much lower costs and improved customization. However, host-based WAFs are more complex to deploy, requiring specific libraries to be installed on the application server, and relying on server resources to run effectively. The WAF also becomes a dependency of the web application which needs to be managed throughout the development lifecycle.
This is a cost-effective option that provides a turnkey WAF solution, with no upfront investment and rapid deployment. Cloud WAF solutions are typically subscription based, and only require simple DNS or proxy configuration to start working. Cloud-based WAFs have access to constantly-updated threat intelligence, and may also offer managed services to help you define security rules and respond to attacks as they happen.
The challenge with cloud WAFs is you need to trust your provider to route all traffic to your web application. If the WAF provider goes down, your website goes down as well, and if performance is poor, your website performance will suffer. This is why most cloud WAF providers offer an integrated WAF, CDN and DDoS protection solution to ensure uptime and minimal latency.
A web application firewall has several possible deployment models:
In each of these deployment models, the WAF always sits in front of the web application, intercepting all traffic between the application and the Internet.
Whitelisting vs. Blacklisting
A WAF can operate in a whitelist model, only letting in known-good application traffic, or in a blacklist model, blocking traffic that matches known attack patterns or security rules.
WAFs intercepts HTTP/S requests, inspects them, and only lets them through if it confirms they are not malicious. In the same way, it inspects server responses, checking them for known patterns of web application attacks, such as session hijacking, buffer overflow, XSS, command and control (C&C) communications, or denial of service (DoS).
WAFs typically provide the following capabilities:
WAFs are deployed at the edge, and attempt to filter and block traffic suspected to be malicious. Traditionally, this filtering was performed using rules, either provided out of the box by the WAF vendor, or customized by the organization deploying the WAF.
The problem with rule-based WAFs is that they require very high maintenance. Organizations must painstakingly define rules that match their specific application patterns, which may change over time as new applications are adopted and as applications evolve. This also makes it more difficult to address changing threat vectors – new attacks might require new rules.
An additional challenge is operating WAFs in a microservices environment. In a large microservices application, new versions of microservices are released multiple times per day. It is simply impractical to deploy a WAF and update rule sets for each component. This means that in many cases, microservices will remain unprotected by a WAF.
Appsec has always been challenging but with the speed of development faster than ever, it has become almost impossible to protect the applications without incurring heavy WAF maintenance or blocking legitimate users.
Check Point’s CloudGuard AppSec uses AI to give customers better security coverage, with lower overheads.
Stop false positives, protect apps & APIs with an automated solution that is as fast as DevOps which provides: precise prevention, Zero policy administration, Automated deployment on any environment.
Start your free trial and secure your apps now.