Evaluation guidelines: This section is descriptive in nature and is provided as background only.
As web application security is essentially a software quality problem, resolving it require fixing the way we design, develop, deploy and operate. It is important to note that this life cycle is more comprehensive than the development life cycle (usually referred to as SDLC) as it includes also deployment and operations. The web applications threats discussed in this document span both the development and operational parts of a system’s life cycle.
Ideally, fixing the security of web applications should be done at all stages since vulnerabilities are introduced in all stage (including operations) lower fixing cost and vulnerability exposure. That said, any engineering process leaves issues unresolved, either because they were not found or because their priority was not deemed high enough.
As a result, protecting a web application will require many complementary security controls, which address the different phases in a system’s life cycle, each one also compensating on issues remaining from earlier phases.
This section is structured along the different phases of an application life cycle, discussing the controls for each phase.
6.2.1 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 number of attempts, enabling an attacker to guess the reminder question answer
- 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 phases making it important to design for security in the first place. Since design is still a human faculty, secure design relies primarily on the expertise of the designers. One way to avoid business logic vulnerabilities is to use existing modules that have been implemented security rather than reinvent the wheel.
6.2.2 DEVELOPMENT
Many if not most application vulnerabilities are introduced during development. To ensure software is developed security, developers must be trained to develop secure software. However, developers’ training is seldom effective by itself:
- 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 effect of security training on developers deteriorates rapidly.
Therefore a secure development program must include direct incentives for secure development as well as repeated training. In addition, introducing early security QA cycles, for example by performing static code analysis as part of the built cycle can enhance developers’ security awareness.
6.2.3 QUALITY ASSURANCE
A large chunk of software security resources is invested in the quality assurance phase. 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.
- 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. 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 remediated, usually by regressing to the development phase, a decision hard to make at the critical phases of a project.
6.2.4 OPERATIONS
While WAFs are the primary tools for protecting deployed web applications, it is important to mention few other important controls:
- Applications are as secure as the infrastructure they run on and using network and server security controls is an important building block of web application security.
- All web applications use of the shelf code, whether it is the underlying middleware or 3rd party libraries. It is important to patch those in a timely manner.
- The secure configuration of the application and middleware is critical
Comments (0)
You don't have permission to comment on this page.