(This is the first chapter of a Web Application Firewall Guidebook to be published in the next few posts)
Before getting into web application firewalls let’s review the problem they solve and alternative solutions. As web application security is essentially a software quality problem, resolving it require fixing the way we develop, deploy and operate software. This process is usually referred to as the software development life cycle, or SDLC for short. The security aspects of the SDLC process are called Secure Development Life Cycle, which confusingly has the same abbreviation: SDLC.
Ideally, fixing the security of web applications should be done at all SDLC stages as vulnerabilities are introduced in all stage. While it is better and potentially cheaper to fix issues early on, no quality assurance is perfect and bugs are carried on to following SDLC stages.
Since there is a cost for implementing security in any stage of the SDLC, when allocating resources we need to make a choice as to where to invest and how much. If any of the solutions outlined below was a silver bullet, the decisions would have been easier, however this is not the case. Is it better to invest a lot in educating developers and having a more secure code but neglect to test or protect the code in the operational environment? probably not, after all no code is vulnerability free no matter how good the developers were. On the other hand, should we only deploy a real time operational control such as a web application firewall? It would be unnerving to release buggy software no matter what automated solutions are there to protect it.
Let’s review the available application security solutions at every stage of the SDLC:
Not all vulnerabilities are implementation bugs. Many stems from the software architecture while others are a result of insecure requirements. An example of such a vulnerability is an insecure password reminder feature. A password reminder is a necessary feature required to lower support cost, yet it is very easy to design insecurely. Two common mistakes in a password reminder feature are lack of lockout after a number of attempts enabling an attacker to guess the reminder question answer and a trivial reminder question too easy to guess, such as a favorite color.
Such vulnerabilities, often called “business logic” vulnerabilities, are very difficult to fix in later stages of the SDLC and therefore it is important to incorporate security in the requirement definition phase and architecture design phases. One way to avoid business logic vulnerabilities is to use existing modules that have been implemented security rather than reinvent the wheel. If a feature has to be implemented from scratch, security experts should be involved in designing it.
The holy grail in web application security is for the applications to be written securely in the first place. Since software is written by humans, those humans are the key for making it more secure.
However, developers’ education and training is seldom effective enough. First and foremost, security is never a top priority for developers and when facing a deadline. They would inevitably prefer to complete a feature rather than focus on security. Additionally, experience shows that the lasting effect of security training on developers deteriorates rapidly.
Today, the majority of software security resources are invested in the quality assurance stage of the SDLC. There are several methods to perform security quality assurance: it can be automated or manual and can inspect either the program code (static analysis) or run time environment. Based on those classifications, security quality assurance can be divided into:
- Manual code review – going over the source code to find vulnerabilities.
- Automated static analysis – automated analysis of source code or binary programs to find security vulnerabilities.
- Penetration testing – sometimes called “Ethical hacking”: trying to hack the application to locate vulnerabilities.
- Application layer scanning – using an automated tool to locate vulnerabilities by exercising the application, usually without actually penetrating the applications.
Focusing on security quality assurance is a double edge sword. On the one hand, vulnerabilities are bugs, and QA teams are experienced in finding them. It is also a convenient phase to involve external security experts in the process to review the software. On the other hand, security quality assurance requires a lot of manual work, even when automated, and therefore is expensive, relies heavily on the expertise of the performer and is difficult to repeat for every change.
Another issue with security QA is that it only detects issues, but they still need to be solved by re-coding. In every QA process there is a decision as to which bugs not to fix. For vulnerabilities this decision is even more difficult.
Since applications are never perfect, it is important to continue to protect the application in the run time environment. The functions that such real time operational controls can provide are:
- Detecting & blocking attack attempts.
- Discovering vulnerabilities not found earlier, even if not exploited yet.
- Detecting unauthorized changes that have not gone through a proper development secure life cycle.
The solution that provides such features is a web application firewall, the subject of this document. Other real time operative solutions that provide some level of protection to web applications are IDS and IPS systems. The next chapter describes the differences.