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 since vulnerabilities are introduces 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.
However everything costs and when allocating resources, a choice has to be made as to where to invest. Resources can be split between the stages, lowering the amount spent on each stage or focus on a specific stage maximizing investment at this stage. If any of the solutions was a silver bullet one, the decisions would have been easier, however this is not the case, and the choice is difficult. 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 are the programmers. On the other hand, should we only deploy a real time operational control such as a web application firewall? Very uneasing to release a buggy software no matter what automated solution is there to protect it.
Design
Not all vulnerabilities are implementation bugs. Some 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 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 setting 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 these phases.
Development
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.
Education and training can enable developers to write more secure software. The OWASP secure development guide and the OWASP education project best signify this approach.
However, developers education and training is seldom effective enough. First and foremost, security is never a top priority for developers and when faced with deadlines, they prefer to complete a feature rather than focus on security. Additionally experience shows that the lasting effect of security training on developers deteriorates rapidly.
Quality Assurance
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 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 difficult to repeat for every change, which are quite common for web applications.
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.
Operations
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 control can provide are:
- Detecting & blocking attack attempts.
- Discovering vulnerabilities not found earlier, even if not attacked 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 book. 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.