Security tests with static analysis 

Given the increasing threat to the security of IT application systems, software testing is expected to uncover a majority of potential security vulnerabilities. But dynamic testing is not the only way to discover security flaws in the system. For example, static analysis of code can be a low-cost way to uncover potential security threats. This may not detect all potential security flaws, but it can detect some of them. (Examples used here refer to Java)

Purpose of the static analysis

Static analysis is one of many testing approaches to find defects in a software system. It is a technique for examining the requirements texts, design models and code components that belong to a software product without actually executing the product. ¹. Design reviews and code inspections are based on the same principle, only they are performed by humans. A static analysis is performed by an automaton that checks for various rules. The goal is to detect defects in the design of the software before the dynamic test. ².

Potential security holes in the code

Many tools are now available for the static analysis of source code. When selecting a suitable tool, the question arises as to the defect types that are reported by the tool. Another question is the frequency of false reports, so-called "false positives". These are reports of defects that are not in fact real defects. When tools bring many such reports, it only distracts from the real defects. As for the real defects, it is important to have a classification scheme. From a code safety perspective, there are five main classes of defects: Missing code, Unauthorized code, Tamperable code, Error-prone code, Non-compliant code. ³.

Missing code

An example of missing code is the missing check of the input parameters of public methods. First it is checked whether the input data have the correct type and whether they are in the valid value range. If not, an exception condition should be raised.

The same applies to return results. Values returned by called methods in remote classes should be checked before they are used.

Another example of missing code is the absence of the "final" clause in a class definition. The fact that the following class is not declared with "final" allows an intruder to copy and manipulate the code. To prevent this, all child classes should be declared with "final".

At least one third of the code should consist of security checking statements. If this is not the case, it is a sign that the execution of the code is not secured ⁴.

Unauthorized code

An example of unauthorized code are built-in constants. Having such values in the code is not maintainable and dangerous. Hackers who gain access to the byte code can modify these values. Therefore, it is recommended to outsource all constants to external resources. This is especially true for texts ⁵.

Other examples of problem areas are casts and nesting.

Manipulable code

An example of manipulable code are built-in SQL statements. They are vulnerable to SQL injection attacks, which allow external parties to corrupt the database content. SQL statements have no place in application code. If they are used at all, then only in a protected access layer. ⁶.

Other examples of manipulable code can be found in the areas of cloning and deserialization.

Error-prone code

Error-prone code can easily lead to an error under certain circumstances. Typical for this kind of defect is the comparison of an object with a string or a recursion without an end condition. As for security, a potential vulnerability exists if the number of parameters in the function call is less than the number of parameters in the called method. In this case the intruder has the possibility to append his own data to the parameter list and in this way spread viruses into the code. ⁷.

Non-compliant code

Non-compliant code involves deviations from a given standard. This is not a direct threat to security, but in some cases it could become one. Take the example when certain standard services are to be avoided because they may be corrupted. Those who apply them in their code anyway run the risk of adopting infected objects.

Case study for the detection of code deficiencies

A study was conducted at North Carolina State University using three million lines of C++ code from Nortel Networks Corporation to show how effective automated static analysis can be ⁸. Using the "Flexlint" tool, the experiment uncovered more than 136,000 defects, or one defect per 22 lines of code, and this was despite the fact that the code had been in use for more than three years. The number of defects from the static analysis correlated with 83% accuracy with the number of defect reports from the pre-release test. This suggests that the defects could have been detected just as well by the static analysis. In contrast to the dynamic test, which cost 12 person-months, the static analysis would have cost only 2 person-months.

Detection of security flaws in Java code

As the study shows, the majority of defects can already be detected in the code before testing. This is also true for security defects, but not for other non-functional defects such as time consumption, data volume, throughput capacity, etc. ⁹. Tools that support testing can be integrated into the development process without much effort (e.g. Continuous Integration). In the age of agile development and continuous delivery of software, defects must be detected and eliminated quickly and without much effort. Static analysis of the code is the best means of doing this ¹⁰.

The following list is intended as an example to show which rules are implemented in such tools. They are taken from the JavAudit tool:

• Avoid allocation of non-initialized objects
• Restrict access to classes and methods
• Finalize all classes and methods
• Prohibit adding new classes to finished packages
• Prohibit the nesting of classes
• Do not allow signature - signing - of the code
• Pack all the code in a single jar
• Define all classes as uncloneable
• Define all classes as unserializeable
• Define all classes as undeserializeable
• Prohibit embedded SQL statements
• Prohibit casting of data types
• Check all initial arguments
• Check all return values
• Put all IO operations in try..catch brackets
• Put all calls to remote methods in try...catch brackets
• Compare the type and number of parameters in each interface
• Avoid the use of hard-coded data values

Conclusion

Experience with static code analysis shows that many security flaws in an IT system are already visible in the code. Static analysis is a cheap, fast and reliable way to uncover these security flaws. All developers need are the right tools and the determination to produce clean code. ¹¹.