Static Security Analysis
Static security analysis methods like manual code reviews or automated taint analysis inspect the code of a software system to find security vulnerabilities. They are always performed without executing the system. This allows a security analysis for partial projects and software systems that are currently not executable. Static analysis enables the detection of security issues as early as possible during the implementation phase of a system, which minimizes the time between introducing and finding a security issue and thus the necessary cost to fix it.
SAST Tool Xanitizer
As a static application security testing (SAST) tool, Xanitizer uses static analysis techniques like scanning, parsing, and taint analysis. During the security analysis, the code is transformed into an internal representation (e.g. a call graph and a data flow graph) and this internal representation is analyzed to automatically detect vulnerabilities. Additionally, Xanitizer investigates not only the source code, but also configuration files and templates for rendering HTML output.
The results of Xanitizer's static security analysis are very accurate. As an example, the OWASP Benchmark project is a Java test suite designed to evaluate the accuracy of automated software vulnerability detection tools. Applying Xanitizer to this benchmark shows that Xanitizer finds all of the implemented security issues out-of-the-box with nearly no false alarms in contrast to other commercial and non-commercial tools. If you are interested in details, you can read our corresponding whitepaper.
Comparison with Manual Code Reviews
It is quite impossible to do a static security analysis in a manual code review for an entire system with hundred thousand lines of code economically. Even for small parts of the system it would require deep knowledge of the security domain to detect all vulnerabilities. Therefore, the probability is very high that not all security relevant code has been read or that vulnerabilities were overlooked by the auditors.
Xanitizer can execute such an analysis automatically, fast and repetitively without overlooking a program path.
Comparison with Dynamic Security Analysis
Dynamic security analysis methods (also known as penetration tests) feed input data into a running software system and gather information about security issues.
It is obvious that the results depend on the currently executed program paths. Selecting the necessary input data to reach each program path needs very high skills and much knowledge about the internal structure of the software system on the side of the penetration tester. But in general, dynamic security analysis handles the software system as a black-box and therefore it usually will not hit each program path, which could cause vulnerabilities to be missed.
A prerequisite for all kinds of dynamic analysis is a running system. Therefore a security issue can only be detected in the later testing phase. As a result the cost to fix a vulnerability increases.
During a security analysis, Xanitizer determines all call relations between methods in the project's code. The result of this process is a call graph that contains all the methods that are reached from a defined set of start methods. This call graph is enriched with further information about objects that have been instantiated in the code, in order to get a more realistic model of the method calls that are in fact possible during the run time of the system.
This call graph might be compared to a system of railroads on which potentially manipulated data can travel, and serves as the basis for the data flow analysis. It allows you to follow potentially manipulated data starting from the entry into the application code, potentially visiting intermediate methods, up to the code location where harm might be caused.
Smart Call Graph
The Smart Call Graph visualizes the generated call graph and allows you to navigate in the control flow of the software system being analyzed. The highest level of the call graph are packages, but it can be expanded via the class level down to the method level. When the structure is not fully expanded, the call relations are aggregated into the class or package level. Using this technique, detail views of single parts of the system can be created, in the context of the rest of the system, but avoiding the chaos that would follow from the whole system being completely displayed. Double-clicking on one of the aggregated arcs expands the graph for all the single methods that were touched by the aggregated arc. Methods unrelated to these are masked in the view, so that it is easier for you to focus on the relevant details.
Data Flow Graph
With Xanitizer's data flow graph visualization you can also inspect a data flow path on method granularity. It shows the methods and their call relations through which malicious data might travel through your software system.
The vertical position of the methods in the graph represents the call depth. Starting from the left-hand side and, at first, climbing up, potentially malicious data moves in the data flow graph via the return values of the called methods to their callers. When the highest call level has been reached, the data value is transferred through methods which are being called downwards towards the end method where harm might be caused. This picture illustrates the metaphor of a railroad system on which data travels, both in the call direction of the methods and in the opposite direction as return values of the methods.
Beside these graphs, Xanitizer has many more possibilities to analyze the flow of harmful data through your software system like an exportable tree representation and directly highlighted code lines.