There are various methods for checking application code for security. One such method is source code analysis, also known as static application security testing (SAST). This article provides an overview of the SAST approach and identifies advantages and disadvantages compared to other testing methods.

The work of an ethical hacker and pentester is varied. In addition to classic penetration tests, in which the pentester takes the position of a black hat hacker, that is, the real attacker, there are other forms of security analysis. This also includes automated application security testing using appropriate tools. We distinguish between different options, including:

Static Application Security Testing (SAST): Here the source code is analyzed “offline”, that is, without running the application.

Dynamic Application Security Testing (DAST). In this embodiment, the application is executed and special inputs are used to test whether the program behaves as expected, reacts unexpectedly, or even crashes.

Feedback-based Application Security Testing (FAST). This is a further development of the DAST approach, in which the input data is systematically refined using fuzzing. Thus, the input is adjusted according to feedback from the application through a mutation mechanism to make more targeted entries in each subsequent round that are designed to trigger errors in the application.

Below we will look at SAST and highlight the strengths and weaknesses of this method.

Source code analysis is often part of the security analysis of a penetration test. The code is confidentially provided to the pentester for testing as part of a white box test. Even code that has been published intentionally or unintentionally (we're talking about "leaks" here) is usually analyzed and reviewed by various parties.

The SAST method has been widely used in practice for a long time and has the advantage that it can be used in the early stages of application development. The source code to be reviewed does not need to be fully executable and functional at the time of analysis because the program is not running.

Instead, the code (also often called source code) is analyzed offline and checked for vulnerabilities. Today's applications often contain many thousands of lines of code and can no longer be tested entirely manually.

Therefore, appropriate tools are usually used that perform automated analysis of the code and check it for possible vulnerabilities. There are various open source and commercial tools for every programming language imaginable. The OWASP project page provides an overview of the tools. Criteria for selecting a suitable tool can also be found here.

Automated analysis using source code analysis tools has a number of advantages. It scales very well and can be repeated at any time, for example if new versions of the software need to be tested daily during the development phase. In addition, such tools find certain errors with high reliability. These include buffer overflows, SQL injection vulnerabilities, and others.

The analysis results include critical lines of code and the exact location in the code so developers and pentesters can quickly identify the problem. On the other hand, such an automated approach does not reveal all vulnerabilities. Authentication and access vulnerabilities cannot be identified in this way.

In addition, exactly how automated analysis can be performed also depends heavily on the code and programming language. In any case, the analyst should also expect a large number of false positives, that is, results that do not represent a real problem. Even though analysis tools can save a penetration tester a lot of work, detailed manual analysis is often unavoidable.

Disclosed sources must be reviewed to determine whether a particular case actually represents an exploitable vulnerability or whether the code in the context is harmless to the integrity of the application. To do this, the analyst must, on the one hand, have a clear understanding of programming concepts and a specific programming language, and on the other hand, have an understanding of the approaches and concepts in accordance with which manual analysis of source code is carried out. This understanding is essential for effective analysis.

What is really important is to understand that any actions taken by software users can be potentially dangerous. For source code analysis, this means that all points at which input data is processed must be identified. This input is also called "Sources". Many programming languages also have a number of potentially dangerous features.

These could be, for example, functions that execute system-level commands, or functions that load and execute other source code. Also worth noting are file operations, which are functions that write something to a file or manipulate it in some other way, such as deleting, modifying, etc. These functions are called “Receivers”.

To find "receivers" you can simply automatically search the entire source code for the corresponding function names. Because the analyst has to focus on the potentially insecure parts when analyzing source code, he can now search for sources and sinks in a targeted manner. Once the relevant parts of the source code are identified, it can systematically understand whether user input from one of the sources reaches one of the sinks.

If so, he must find out under what conditions this occurs, because the vulnerability does not always have to be present immediately. If the input data has been sufficiently tested, modified and secured on its way to the receiver, there is essentially no problem.

However, it often happens that over time the code becomes very complex and confusing even for developers. The more features and functions are built in, the more likely it is that user input will be processed in ways that developers don't expect.

When analyzing source code, an analyst can approach it from different angles. For example, if there are many receivers, but few sources, then it makes sense to move further through the code and check all possible source paths. If there are few receivers, he can go back through the code and see if one of the sources can be traced.

This approach can detect many critical issues, but unfortunately it is not enough to focus on user input and potentially dangerous features. The analyst can now rule out the possibility that the user could execute code or inject something malicious, but he still knows little about the logical structure and functionality of the program.

Therefore, after a rough overview, it is worth breaking the code into separate functional parts. Which part of the code is responsible for authenticating users? Is there a password reset feature? Where exactly does the code interact with the database? These and other questions need clarification, and these are just a few examples of how parts of an application can determine security. First of all, you should pay attention to how the code is logically structured, what checks are there, what functions are used for checking, and how complex and confusing the code actually is.

It becomes clear that SAST is an important application security analysis tool, but not a panacea. Due to the numerous false reports of the SAST tool, there is a risk that important errors will be missed during analysis. Despite automation, such analysis often takes a long time if all reports have to be checked for relevance.

Additionally, SAST tools struggle to cope with today's increasingly complex environments because many functions are integrated from external sources and therefore, in some cases, all source code is not always available. Therefore, static source code analysis should be complemented by other methods. In any case, Dynamic Application Security Testing (DAST) and its variants are ideal.

This approach involves interacting with the program at runtime to test its feedback and responsiveness. This has the advantage that very few false positives are generated, but on the other hand there is a problem: even if the input values are carefully chosen, not all the code can be tested. Each form of analysis has its own advantages and disadvantages. Therefore, the analyst must clearly understand the implications of the option used and its limitations.

Mainton Company - custom software development and testing, SEO and online advertising since 2004.