Automated Code Review

Static Application Security Testing

Static Application Security Testing (SAST) refers to using automated tools for code analysis. The idea is not to replace manual code reviews but to provide a simple method to automate simple code checks to quickly find vulnerabilities during the development process without requiring a specialized individual.

SAST complements other techniques, such as Dynamic Application Security Testing (DAST) or Software Composition Analysis (SCA), to provide a holistic approach to application security during the development lifecycle. Just as with any of the other techniques, SAST will have its pros and cons that we need to be aware of:

Pros	Cons
It doesn't require a running instance of the target application. It provides great coverage of the application's functionality. It runs fast as opposed to other dynamic techniques. SAST tools report exactly where vulnerabilities are in the code. Easy to integrate into your CI/CD pipeline.	The source code of an application is not always available (third-party apps). Prone to false positives. Can't identify vulnerabilities that are dynamic in nature. SAST tools are mostly language-specific. They can only check languages they know.

SAST Under the Hood

While every SAST tool is different, most of them will perform two main tasks:

1. Transform the code into an abstract model: SAST tools usually ingest the source code and produce an abstract representation for further analysis. Most SAST tools will represent the code using Abstract Syntax Trees (AST), but some tools may have other equivalent proprietary structures. This allows for easier code analysis in a way that is independent of the programming language in use. This step is crucial for later analysis, as any feature of a programming language that isn't correctly translated into the AST will probably not be analyzed for security issues effectively.

2. Analyze the abstract model for security issues: Different analysis techniques will be used to search for potential vulnerabilities in the code model.

During this room, we won't cover code modelling in detail, as you won't have to deal with it from a user's perspective. We will instead focus on the different analysis techniques commonly used by SAST tools:

Semantic analysis

This type of analysis can be compared to grepping for potentially insecure functions while doing manual code reviews. It aims to find flaws concerning the use of potentially insecure code in a localized context.

Examples of this include searching for calls to mysqli_query() where GET or POST parameters are directly concatenated into the query string:

mysqli_query($db, "SELECT * from users where username=".$_GET['username'])

Dataflow analysis

There are situations where potentially dangerous functions are in use, but it isn't clear whether or not a vulnerability is present just by analyzing the local context around the function call. Take, for example, a function defined as follows:

function db_query($conn, $query){
    $result = mysqli_query($conn, $query);
    return $result;
}

By looking at the function's code, it's hard to say if there are any vulnerabilities. Analyzing the local context of the call to a dangerous function is not enough in this case.

Dataflow analysis will trace how information flows from inputs the user can manipulate to potentially vulnerable functions, just as we did when manually analyzing the provided application's code. In dataflow analysis terminology, data inputs will be referred to as sources, and potentially vulnerable functions will be referred to as sinks. If data flows from a source to a sink without sanitization, we have a vulnerability.

Going back to the db_query() function, dataflow analysis would have to find all of its usages and trace back to see if any tainted input (the source) is sent to it, finally ending up as part of the query executed by mysqli_query() (the sink).

Control flow analysis

Analyzes the order of operations in the code in search for race conditions, use of uninitialized variables or resource leaks. As an example, look at the following piece of Java code:

String cmd = System.getProperty("cmd");  
cmd = cmd.trim();

If the cmd property isn't defined, the call to System.getProperty() will return NULL. Calling the trim method from a NULL variable will throw an exception on runtime.

Structural analysis

Analyzes specific code structures of each programming language. This includes following best practices when declaring classes, evaluating code blocks that may never execute (dead code), correctly using try/catch blocks and other issues related to using insecure cryptographic material (weak keys or IVs).

Here's a quick example of code that would be detected by structural analysis:

$options = array('private_key_bits' => 1024, 'private_key_type' => OPENSSL_KEYTYPE_RSA);  
$res = openssl_pkey_new($options);

In this case, we have an implementation of RSA with a key size of 1024, considered insufficient by today's standards.

Configuration analysis

Searches for application configuration flaws rather than the code itself. As an example, applications running under Internet Information Services will have a configuration file called web.config, PHP will hold all of its configuration options in a file called php.ini, and most applications will use some configuration file. By checking configurations, the tool will identify possible improvements.

Here's an example of two configuration directives in PHP that would probably raise an alert on SAST tools, as they facilitate some attack vectors for RFI, SSRF or other:

allow_url_include = On
allow_url_fopen = On

It is important to note that not every SAST tool will implement all the analysis techniques we discussed, but it is good to have them as a reference to compare different solutions out there.