A WAF like security solution is normally used for securing web applications in order to protect against attacks on the (web) application layer. It filters incoming requests which could exploit typical application programming errors as application weaknesses or other vulnerabilities on the application server. The WAF focus is limited to web technologies which means everything which is transported on top of the http protocol and which involves a web browser like client and a web application server. This sounds innocent, however, it means handling a complex amalgam of different technologies securely which is a daunting task.
Similar solutions which would do the same thing on non-web applications are usually not using the WAF label (e.g. FTP or SNMP gateways or proxies etc.), however, they might be known as having application layer firewall functionality. Many such non-web applications (including their protocol stack) are simple and require less effort to implement and to secure than web applications. Such application layer firewall functionality might even be supported within a normal perimeter firewall, probably marketed as next generation firewall offering deep packet inspection.
Today, a large portion of non-web IT traffic is now also tranported over the http channel. It turns out that http is already open on many network firewalls for facilitating web browsing. Using this port on the network firewall is therefore attractive for many other communication services or applications. This property has been dupped http as being a ‘firewall friendly protocol’ which, however, is now a huge security concern. A modern network firewall is supposed to distinguish between http content using deep inspection and filter accordingly, but nevertheless, it would still be unable to cope with the complexities of a real web application, hence the need to have dedicated WAF like filtering solutions besides the normal firewall.
Where to implement it?
A WAF can be implemented as part of the application on the same server or independently in front of the application as reverse proxy. Another frequent deployment scheme is to hide it by using the so-called transparent mode (bridge setup). However, the approach as reverse proxy has probably most potential to create added value for an enterprise IT because it can provide much more useful services than just filtering. Such WAF solutions are like network routers – however only for the http protocol.
Maybe that is also the reason why WAF products in the shape of hardware network appliances are so popular. A software based solution might do exactly the same thing, furthermore, it provides more flexibility if the time comes to scale up or to upgrade. Nevertheless, this flexibility comes with a cost as a dedicated server infrastructure needs to be operated. It is therefore helpful if the software appliance WAF is already bundled with its own (hardened) OS.
Why not develop secure applications instead?
This is a great question because a WAF would actually not be needed in the perfect world! A perfect world, where
- all applications are developed with all security guidelines in mind.
- all applications developers interpret these security guidelines in the same correct way.
- all application developers are security specialist and master all relevant security technologies.
- all applications are tested without missing one single security problem.
- all operators and developers have plenty of time to fix the new security hole which was just published in the media.
- the bad guys would behave like gentlemen and wait a bit after publication of security holes before starting their attacks.
Unfortunately, such a world does not exist. Furthermore, web applications can attain a level of complexity which simply is difficult to secure. It still is very easy to argue that such mistakes should not happen. However, it is unrealistic to expect that all developers become security experts at once when such issues pop up and when business and IT department are already in panic mode. The realities in the IT industry are complex and not benevolent for security. Having a WAF solution as additional layer of defense is a wise approach.
A WAF becomes also a necessity because of the way IT applications are operated. Professional web applications often run in large numbers in farm like IT environments. They are usually operated by professional operators who would not know many application details, yet coding details. The work ethic is to follow strictly defined operation guidelines in the production environment and not to change one single bit out of the blue. The goal is to have a stable environment and to prevent further uncontrollable damage.
Many system failures have their root cause in a quick fix done by a good meaning system administrator creating side effects far beyond the expected. It really makes sense to restrict such system changes. The professional approach is to go through a strict change procedure cycle of testing, stake-holder meeting with approvals, scheduling maintenance windows and having rollback plans ready just in case. Obviously this is time consuming, therefore, such change windows are only available a few times per month, in extreme cases a few times per year only.
In large and complex IT environments, chasing and fixing hundreds of applications for a vulnerability just published in the media becomes under such circumstances a pure act of force. Repeating such an exercise every time someone reports a vulnerability would not be feasible in most such IT organizations.
WAF business case: Virtual patching
Here is one of the WAF business cases: Operating as security filter on behalf of applications. A vulnerability can be patched virtually on the WAF centrally for all applications concerned.
This feature is also beneficial, even if you would consider the security of all your applications and the security know-how of all your developers and contractors being state of the art. A WAF will support catching such issues centrally for all applications, thus buying precious time for fixing and improving the applications in the next development cycle without the need to block your precious IT resources.
Doing it in an orderly way relieves many of your resources from the time and energy consuming task of exception and incident tracking.
Inbound WAF scenarios: Central Web Access Server
Nevertheless, there are another good reasons for having a WAF. If the WAF is versatile enough as part of a larger web delivery and access infrastructure, then it is delivering value-added services to business:
- Swiss style Web Entry Server approach as central security access point and authentication enforcement point to all web applications.
- A WAF with VPN support can provide secure remote access to web based applications on the Intranet.
- A WAF with portal support provides a secure platform for creating or operating Internet or Intranet portals.
Outbound WAF scenarios: Forward proxy
Above scenarios are inbound only, however, a WAF like outbound solution can also be used in forward proxy scenarios.
- A WAF with dedicated SOAP/XML support can protect internal business applications when they use (connect to) external SOA based web services
- A WAF with adequate payload inspection can protect internal business applications when they use (connect to) external file transfer services on http protocol layer
Such scenarios sound unusual as forward proxies are rather known as securing the external browser traffic, e.g. preventing an employee to browse on malware infected web pages or preventing data leakage.
Examples of such outbound WAF solutions with SOAP/XML filtering capabilities have been implemented in the Swiss financial industry as security infrastructure for securely consuming external SOA web services from payment business partners (i.e. validator proxy solution).
2016/02/05, last update 2018/07/04 ©ACROSEC Inc.