Buffer overflow attacks have been understood since 1972, and yet buffer overflows still dominate the warning lists of security analysts today. In this article, I make a plea for compliance with coding standards, more and better source code reviews, and the use of good tools for static analysis that can improve quality and security.

Lack of training and inadequate quality assurance and checks are the root causes of breakdown-prone software. As early as 1972, scientists described the first, albeit theoretical, buffer overflow attack [1], and SQL injections [2] have been around since 1998. Both still account for the majority of IT security vulnerabilities today, and both can be easily avoided: buffer overflows with n functions (e.g., strncpy() instead of strcpy()) and SQL injections with prepared statements. But who makes sure developers adhere to these practices?

Although coding standards that prescribe secure functions would help avoid repeating these classic errors, hardly any company or project even lays down mandatory rules, let alone monitors compliance with them. Therefore, very few developers tend to orient their work on security targets.

Brackets and Indentation

Having to check manually whether a fellow programmer has, for example, correctly indented their curly braces is unlikely to make code review a more attractive task. Tools can and should do this kind of no-brainer work, but they have to be flexible.

Opinions differ, even in terms of the visual arrangement of curly braces and their indentation depth. Although I can never completely shake off my Pascal past and always start a block in a new line with a bracket (Pascal begin style), many view the loop header or the condition as sufficient and place the opening bracket at the end of the line. The pseudocode in Listing 1 illustrates the differences.

01 if (x == y) then
02   {
03      do something;
04   }
05
06 while ( x < y) {
07   x = x+1;
08   }

The indentation depth in the source code is equally a matter of interpretation. Two spaces? A tab? What is the maximum number of spaces equivalent to a tab?

Although a supporting tool can clean up indentation, will it enforce the ban on strcpy() and other functions that are tagged as deprecated? As an example, you can find a comprehensive example of C coding standards for the development of embedded software online [3].

Some development environments, such as Eclipse or Vim, support full or partial compliance with standards out of the box, as do independent programs such as Uncrustify [4].

School of Life

Even a visual cleanup can help you identify errors in control structures. I learned this early on in school when a learning program written by my teacher suddenly started to behave in a peculiar way. Thanks to me commenting on it, she handed me the source text with the homework task of removing any potential bugs.

The code was a mess: sometimes indented, sometimes not. After running a code beautifier against it, it turned out that the block ends were chaotic and random. To keep the compiler from complaining about not having enough block ends, the teacher had simply moved them elsewhere. As this anecdote shows, errors can be avoided simply by adopting visually clean programming techniques.

JSLint: Bane of JavaScript Authors

Code analysis tools go one step beyond a clean approach. For JavaScript, for example, JSLint [5] offers an online check, which you can see in Figure 1 testing the quadrat.js script I borrowed from an online tutorial [6]. You can restrict the far too detailed criticism by telling JSLint to restrict itself to one browser. Nevertheless, in some cases, it is simply too harsh. For example, it likes to criticize the handling of quotation marks, although generally accepted references [7] take a far more relaxed view of this issue.

Figure 1: JSLint complains about a sample program (CC BY-SA 3.0 [8]; German translated to English).