When web based applications become important components of business IP, protecting these applications is a key part of doing business. Most of IT and DevOps professionals are not thinking whether they need a Web Application Firewall (WAF). Instead, they are trying to decide which WAF is right for them. We are going to look at several key factors in WAF selections.

Deployment architecture

There are two different ways to install WAF for the modern web: first tier/load balancing stage and last mile right on the application.

First tier means that you have WAF installed as a part of load balancer stage (for example integrated with NGNIX Plus load balancer) or using AWS WAF or a WAF from your cloud provider. This way assumes that you have SSL/TLS certificate installed on the WAF side. If WAF is an external cloud service, this may mean exporting SSL / TLS certificates out of the enterprise to your provider.

Last mile installation option is a way to protect your application by the WAF installed right near the application server. This way is also known as “secured” or “protected container” when the developers can use only containers like a Docker with pre-installed WAF inside to deploy their apps. The later option is only available with software WAFs.

Security Rules

Legacy WAFs tend to rely on attack signatures to decide which requests might be malicious. Without new signatures that are modified to catch ever-changing hacker attacks is what makes WAF are unable to detect anything except, perhaps, the most basic attacks that should have been patched anyways. If one is looking at an open-source WAF, chances are, it may not even have a commercial signature feed available, which makes it moderately useful in a production environment. Even for those commercial WAF where signature feeds are available, the signatures are generic and are written based on what hacker might do, not how the application might react. In addition, security rules still need to be created based on the signature feed. That means a security professional needs to be involved in operating a WAF and spend time creating new security rules on a regular basis.

Newer Next Generation WAF, like Wallarm, rely on AI and machine learning to continuously update security rules based on the application behavior, rather than relying on a generic external signature feed. This approach makes false positives far less likely.

“…rule-based security is inadequate, especially as organizations exploit more cloud-based services and open APIs for customers and partners to integrate with their systems.

David Cearley, Vice president and Gartner Fellow, Gartner

Cost of false positive / blocking

As with any security tools, it is paramount that security does not block legitimate business requests. Combined with a high level of false positives, this broad blocking can cripple the application and result in significant customer dissatisfaction. This is the reason why many operations professionals choose to run WAF in monitoring rather than blocking mode.

Two common approaches are IP ban and by request blocking. IP bans are very expensive and may result in long term blocked business or blocking of entire regions, especially in the cases where service providers or mobile networks are involved.

The other question is how quickly a company can react to a false positive. If something is blocked and impacting the company business, you may need to react fairly fast with the following actions:

  • Unblock the traffic
  • Disable or modify signatures to avoid similar requests being blocked in the future

How difficult these two operations are and how difficult it is to distribute these configuration parameters to all the WAF control points is a critical consideration in WAF selection.

If you want to avoid reviewing suspicious requests by hand, look for a WAF that can block selectively, based on the individual API or http requests.

Supported Protocols and Data Formats

While older WAF assessment methodology mostly called for support of

  • HTTP/0.9–1.1
  • Extensible Markup Language (XML) including SOAP
  • Javascript (JS)

Newer applications have far increased complexity, including many nested (matryoshka) protocols with complex built-in structure, as well as real time protocols.

For example, exploit for Magento <= (https://vulners.com/packetstorm/PACKETSTORM:135941) is a base64 encoded JSON.

GET /magento/index.php/rss/order/status?data=eyJvcmRlcl9pZCI6MCwiaW5jcmVtZW50X2lkIjp0cnVlLCJjdXN0b21lcl9pZCI6dHJ1ZX0=
Host: localhost

To block the attack for this vulnerability, WAF should decode the ?data parameter at /magento/index.php/rss/order/status URL as a Base64 first and then decode the result again as a JSON.

Look for WAFs that support Java Script Object Notation (JSON), Asynchronous Javascript and XML (AJAX), HTTP/2, WebSockets, Base64, ASP.NET VIEWSTATE, PHP serialization and their encapsulated variants like XML inside of the JSON and so on.

Integration with DAST

Last but not least, it is important that the new releases of the application, as they come out, are checked against a known set of possible vulnerabilities. This feature is particularly important in the environments that follow CI/CD practices and tend to push out new releases several times a day. When selecting a new Web Application Firewall, it is important that integrates with Dynamic Application Security Testing.

One way to integrate is to grab the payload from an attack detected by WAF and use it in the DAST application testing.

The other useful integration it to take the results of DAST testing and ensure that production versions of the same application are protected from the vulnerabilities found by the DAST tools, i.e. virtual patches are applied.

Most of the quality WAF products out there support free or inexpensive trials. So, once you have made sure that your top contender satisfies all of the above criteria, you should probably test it in your own infrastructure. Seeing it working in your own environment is always better than hearing about it from somebody else. Happy testing.