Today, attacks on web-based systems hardly target weaknesses in network protocols anymore but rather flaws in applications. Many of the spectacular security breaches in recent years, such as the one on the Sony PlayStation Network, took advantage of programming defects in web applications. The defects are rarely exotic and can be grouped into just a few categories; for example, the Sony hack succeeded with an SQL injection.

Modern operating systems do provide elaborate protective measures against vulnerabilities, such as address space layout randomization, but savvy attackers can circumvent these protections with a few tricks. The only real solution is to develop web applications without security vulnerabilities. Systematically avoiding programming defects is therefore the noble aim of any serious software quality management.

Secure programming begins long before the first line of code is written: In the design phase, developers should consider which safety issues could arise, which safety requirements are necessary, and under what conditions the software will be used. By then, at the latest, the project should specify coding standards so that tests and code reviews all speak the same language.

Engineers know that quality is a result of the production process and cannot be tested in the product afterward. OpenBSD is a positive example of building quality into the process. Many consider the OpenBSD version of Unix the most secure operating system, thanks to clear quality standards and tests. From the beginning, all developers involved in a project must take care to ensure safe and error-free code. In addition to providing continuing professional education, the OpenBSD team maintains a collection of routines for standard cases. These routines mean that developers won't have to re-invent the wheel and make mistakes that have already been corrected.

1. Do Not Reinvent Anything

New wheels and new software do not run as smoothly as projects already proven in practice. Many developers write their own routines for session management and login validation, often leaving the doors wide open for session surfing or SQL injections (Figures 1 and 2).

Figure 1: Good tests would have brought to light that the login screen of the security demonstration site Badstore.net allows SQL injections; …

Figure 2: … thus, anyone can see what other customers have ordered. This harmless dry run also works with a frightening number of real shops.

2. Review Code

Two very simple measures protect against intrusions and inspire best practices: For one, it helps to agree within the project who will be responsible for which routines from which libraries. For another, having each of the developers audit the code of another also improves the quality. Agreements reduce the likelihood for redundant inventions because one person often will already have a solution for a standard problem.

At the same time, such agreements also lead to a second quality assurance effect: A developer who has to explain his code to someone else will document it better and be more thorough. Furthermore, the results of mutual code presentations can be used directly for the documentation – an issue that is often neglected.

Such consultations are far from being the systematic code reviews in which a second developer or even a whole team scrutinizes the programming of a colleague line by line. Such testing is very time consuming, but it promises – provided you have a good team – a very high chance of successfully finding errors. OpenBSD invests in this effort.

Intensive reviews don't just result in the discovery of security problems; they also help developers heighten awareness of critical programming errors, and they lead to improved documentation.

3. Check Input Effects with Data-Flow Analysis

A data-flow analysis in the framework of the code review is helpful in the search for security loopholes. For each piece of data that is entered, it is important to investigate whether and how it might influence other processes. This process is easily done for simple mail forms, but it is very time-consuming for database applications. Experience shows that a data-flow analysis is the best way to catch problems that might lead to cross-site scripting, code injections, and similar points of attack.

In such data-flow analyses, the extreme values are always of interest: For example, should an integer variable exceed PHP_INT_MAX, PHP automatically performs a typecast to float. This can have surprising effects should the value finds its way into a database field of the integer type. Integer overflows can happen easily in database systems such as MySQL that also use data types like tinyint.

When performing a data-flow analysis, developers must keep an eye on all calculations and manipulations of input data related to limits.