I bought a shiny new application firewall. Now don't tell me that isn’t enough!
An application firewall stands between the web server and the user’s browser. It intercepts all traffic to and from the web server. The traffic is checked against various rules to determine if it's "good" or "bad".
Rules are developed in two ways:
- From a database of known attacks either through signatures of actual attack data, behavioral patterns, or hybrid of both.
- By observing the application's functions and generating a set of policies that define acceptable input from the user.
- Session Hijacking, when session tokens are assigned weakly. The firewall would have no clue as everything in the session hijacking attack appears to it as a valid normal session.
- Privilege escalation attack, when an adversary manipulates an input to that of a higher privileged user. Since the firewall is unable to verify the authorization level of the user, it lets the attack go through.
- Stolen passwords, when the application stores passwords on the client. There is no way an application firewall can prevent it from getting stolen.
- Insider attacks
But application firewalls can be thwarted. Many attacks use legal characters to probe Web applications and get access to sensitive or restricted pages. Here're some examples where application firewalls fail to protect your app:
An application firewall can provide an additional layer of security for the application. As such, it is possible that some novel attacks may be thwarted before they can reach the application. However, they cannot be a substitute for sound, secure programming practices. Relying on an application firewall to protect bad software is destined for an eventual failure of the application. Thus, the best solution would be to combine some form of external protection via an application firewall with securely coded applications.