Lead Image © Andrey KOTKO, 123RF.com

Lead Image © Andrey KOTKO, 123RF.com

Static code analysis finds avoidable errors

At the Source

Article from ADMIN 53/2019
By
Static code analysis tools like JSLint, Splint, RATS, and Coverity help you find code vulnerabilities.

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.

Listing 1

Two Ways to Indent Code

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).

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • From debugging to exploiting
    Kernel and compiler security techniques, together with sound programming practices, fend off memory corruption exploits.
  • Kernel and driver development for the Linux kernel
    The /proc filesystem facilitates the exchange of current data between the system and user. To access the data, you simply read and write to a file. This mechanism is the first step for understanding kernel programming. ü
  • Tuning I/O Patterns in Python

    In the third article of this three-part series, we look at simple write examples in Python and track the output with strace to see how it affects I/O patterns and performance.

  • New features in PHP 7.3
    The new PHP 7.3 simplifies string handling, supports PCRE version 2, adds LDAP controls, improves logging, and deprecates some features, functions, and syntax elements.
  • Tuning I/O Patterns in C

    The language you choose to use affects I/O patterns and performance. We track a simple write I/O pattern with C and look at how to improve performance.

comments powered by Disqus