Techniques Used by Static Analysis Tools:
Static analysis tools are unique because they test the code without knowing or requiring any external states to be set. Since the Static Analyzer does not know what the application or function is intended to do it will not make assumptions that a developer or code reviewer might. In this section the techniques used by the static analysis tools are discussed and each technique is outlined in detail in the following paragraphs.
Semantic checking
Semantic Analysis allows the analyzer to discover the basic structure and relation of each function within the application. This helps the static analysis tool to better understand how the application will run after build time and to find bugs deeper in the code base. In this part of the analysis an abstract syntax tree can be built to run simulations of each of the functions to calculate how the application will execute.
Strong type checking
This helps ensure the programmer does not make any dangerous type casting assumptions such as accidentally attempting to cast a float or decimal value to an integer type at runtime. This helps ensure round off errors and type conversion errors do not happen at runtime. If the programmer knows that the type conversion will never happen or has taken other cautions to prevent the error then the warning can be safely disregarded.
The static analyzer checks for un-initialized or possibly un-initialized variables. By following the code path from the first declaration of the variable to see if the variable is used before it is assigned to, or if the assigning function may return an invalid type for the variable, the tool can catch possibly un-initialized variables.
Memory allocation checking
Some static analysis tools can check to see how memory is being allocated to find cases where memory is being improperly used. If memory is being allocated but no deallocation can be found this might indicate a memory leak. Deallocating memory that is not allocated within the same function may cause the application to crash if earlier allocation attempts fail. Many static analysis tools also can catch bugs due to mismatched memory sizes.
Logical statement checking
This feature allows the Static Analysis tool to discover logical statements that will always evaluate to the same result. This is accomplished by remembering all the possible values or ranges of the variables being evaluated in the statement then building a logical table. If all statements resolve to the same outcome an error is reported
Interface and include problem checking
Checking how each helper file defines other needed references can lead to other dependency problems. For example header file include cycles can be discovered as well as the unnecessary use of extra include files whose removal may speed up compile time or reduce security exposure.
Security checking
Many security checks can be performed before compile time. Some system API functions are dangerous and should be only used with proper error checking, other functions are dangerous and should never be used. Possible Buffer Overrun conditions can be predicted so the developer may be able to fix them before they are discovered and exploited through the application. Time of check – Time of use problems can be discovered at build time as well, these errors occur when the application assumes that a resource has not been changed between the time it was checked and the time it is used. Other functions open the application to unnecessary security risks and can be mitigated by replacing these functions with similar, but moresecure functions.
Metrics
Metrics can help a developer understand where there is unnecessary complexity in their code or metrics can generate helpful statistics for the application. Functional file coupling reports the relationships between the files of the application – uses and used by – and a metric that sums them both. Functional file cohesion shows other metrics within the file such as lines of code, number of methods, level of inheritance, and many others. Class level metrics allow the developer to gain an understanding of the cohesion of the application at a class level view. Cyclomatic complexity shows how many independent paths through each module the application can take; more paths can mean more complexity. Other useful metrics such as the ratio of comments to functional source code can point to places in the code that should be commented more effectively.
Simulator
The simulator is at once the most powerful and the most highly guarded part of the static analysis tool. The basic premise is as follows: the simulator selects a function and generates data based on each of the variables. If information exists about the possible data ranges of the variable then those ranges are used, however if no constructs are found for the data type then max and min are used as limits for the generated data.
Once the data has been generated the function is followed through each code path to hit each line of code. Function calls within the simulation can either be followed to their declaration, thus simulating another function or the return value of the function call can be generated for testing purposes.
This allows the simulator to test small sections of the code without requiring it to be compiled into the final executable application. Testing code this way can help alleviate some of the shortcomings of traditional static analysis tools.
Crawl source code
These tools can crawl the source code of the application mapping out each possible code path and discover unused or unreachable code. By mapping the possible values of a logical statement the analyzer can determine if the statement will have a constant outcome. Other difficult to determine problems with peer reviews can be quickly analyzed through sample values and logic tables; this can drastically speed up white box testing time. Unused or unreachable (dead) code poses a possible security risk to the application. Dead code is orphaned and unreachable so it remains untested throughout the product cycle. In a future release, a bug fix or code modification may allow the dead code to become active, thereby exposing untested security vulnerabilities or other functional flaws. Under certain extenuating circumstances a skilled hacker may be able to circumvent current constructs within the application and execute the untested code which may contain exploitable security flaws.
| <<Previous | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | Next>> |
Provided by: Security Innovation, The Application Security Company