I recently deployed Radware’s Web Application Firewall (WAF) aka AppWall in a hands-on lab anybody is welcome to try out (message me for more info). I thought I would provide a WAF 101 post for those unfamiliar with the topic and well as showcase Radware AppWall.
To summarize firewalls, they permit and deny traffic. Overtime, firewalls have combined capabilities with other security tools include adding application-layer visibility, application controls, intrusion prevention and antimalware to name a few of the “next generation” features. The term “Next-Generation Firewall” has been defined many ways but essentially it means a firewall that can view all ports and protocols, control traffic down to the application layer and some people also include in the definition exploitation prevention capabilities.
Exploitation defense in a
Data can also be exposed if poor web application security is deployed. This next example shows the classic something or 1=1 attack, which tricks the vulnerable application to grant access even though the user doesn’t know the right password since 1 always equals 1.
A next generation firewall would not prevent either of these attacks hence the need for a WAF.
There are many benefits of a WAF, which include preventing web-based exploitation, validating input, filtering sensitive information such as converting credit card numbers to XXXXXX’s and preventing different forms of denial of service attacks. There are a few ways a WAF can be deployed to protect web applications. The most common method is deploying it as an inline gateway or configuring the WAF to act as a proxy.
The previous image shows the AppWall configuration tab displaying some of the filters that can be enabled. If a filter is violated, a customized block page can be generated as shown below. This is not only ideal for showing that security is enabled to defend the attempted attack, but this customized message also hides error messages or other data that could disclose information about the web application being attacked.
If an attacker continues to attempt exploitation against a protected web application, AppWall can add that source to a blocklist as shown below. This will prevent brute force and automate response when reconnaissance and exploitation is being repeatedly executed by an attacker.
To test data loss, the next example shows how I used a real credit card number in the output from a web application. The example represents a customer putting in their bill identifier and their information is displayed including what credit card number was recently billed. AppWall auto hid those numbers by replacing the digits with XXX’s.
There are many more benefits