static code analysis (source code analysis – sca) - jackson state
TRANSCRIPT
Static Code Analysis (Source Code Analysis – SCA)
Dr. Natarajan Meghanathan
Associate Professor of Computer Science
Jackson State University
E-mail: [email protected]
Static Analysis
Static analysis consists of analyzing a piece of code without executing it.
A well-done static analysis will consist of the following categories:
• Type checking• Style checking• Program understanding• Program verification• Property checking• Bug finding• Security review
Type Checking
Type checking is what most people think of when they think of static analysis, and it is certainly an important part.
Type checking is usually done by the compiler, before the program is compiled.
Type checking is usually not perfect, though, and the compiler can generate false positives and false negatives.
Type Checking
Which of the following will fail the Java compiler’s type checking?
public void methodA()
{
short valA = 1; //valA = 1
int valB = valA + 1; //valB = 2
short valC = valB; //valC = ?
}
public void methodB()
{
int valA = 1; //valA = 1
String valB = "" + valA + "A"; //valB = "1A"
int valC = Integer.parseInt(valB); //valC = ?
}
Type Checking
You might be surprised to find out that
methodA() which converts a short to an int,
adds 1 to the value, and tries to convert back
to a short will fail the compiler’s type checking
mechanism.
According to the compiler’s specifications, it is
never acceptable to convert an int to a short
because it may result in a loss of precision.
Type Checking
This result represents a false-positive for
type errors.
The actual code in which the int is converted
to a short will not result in any precision
loss, since the value of “2” is still a short
value.
Type Checking
The fact that no error was raised for methodB() illustrates a false-negative.
Converting the string “1A” to an int will result in a NumberFormatException at runtime, but the compiler does not issue an error because converting a string to an int is often acceptable when using the Integer.parseInt() method.
In this case, however, this is not a legitimate usage and should be uncovered.
Program Verification
Program verification checks involve comparing a specification with a block of code to ensure that the block of code accurately represents the specification.
The importance of program verification is not in uncovering runtime errors, but in uncovering logic errors. Program verification can be performed on a particular implementation of an algorithm to ensure that the implementation is correct.
Program Verification
The program verification process would verify that the implementation provided below matches the specification provided.
Specification: Calculate the total price of an item with full-price P, discount D, and sales tax T.
public float totalPrice(float P, float D, float T)
{
float total = ( (P – D) * T) + P;
return total;
}
Program verification uncovers that, while this might look right at first glance, it does not yield the proper answer.
Program Verification
The specification asked for the total price of an item with starting price P discounted by D and with sales tax T applied.
For starting-price of 100.00, a discount of 20.00, and a tax of 0.05 (5%), the method returns a value of:( (P – D) * T ) + P
= ( (100.00 – 20.00) * 0.05) + 100.00= 104.00
Where, the proper way to calculate the result would be( (P – D) * T) + (P – D)= ( (100.00 – 20.00) * 0.05) + (100.00 – 20.00)= 84.00
Fortify Source Code Analysis
Tools and Exercises
Fortify SCA
Fortify Source Code Analysis features two tools
which will be covered in the following modules.
•Fortify Source Code Analyzer performs a static analysis of Java source code.
•Audit Workbench allows a user to review the results of a static analysis.
Fortify SCA
The Fortify SCA tool will perform a static analysis on a set of source-code input files.
The command-line tool will alert the user to any vulnerabilities or flaws in the program being analyzed.
The tool can analyze either a single file, or an entire application consisting of many files.
Audit Workbench
The Audit Workbench allows a user to review a completed audit.
Results can be fine-tuned so that only specific types of issues are flagged.
The user can also create custom rules for audits which will allow the program to check for various things the user may want to find.
Audit Workbench
The Fortify SCA will check code for a number of vulnerabilities and evaluate the threat they pose with the
following categories:
•Reliability issue
•Bad practice
•Suspicious
•Dangerous
•Exploitable
•Exploit available
Static Analysis
Analyzing a large project with tens-to-
hundreds of thousands of lines of code can
become quite an undertaking when done by
manually.
A source-code analysis tool like Fortify SCA
makes this process much quicker and
simpler.
Source Code Analyzer
The Fortify Source Code Analyzer tool can
be run from the command-line in Windows and Linux.
The command to run the analyzer is
“sourceanalyzer” followed by the name of a
source-code file to analyze.
Source Code Analyzer
There are a number of command-line options which control the sourceanalyzer tool.
-f <file> : specifies the name of an output file to create
-html-report : creates an html file which provides a brief summary of the report
-scan : runs analysis portion of the source code analyzer
-findbugs : runs the findbugs utility
-rules <rules-file> : specifies a particular rule pack to use
Source Code Analyzer
Example uses:
sourceanalyzer *.java
- runs the source analyzer on all .java files in the current directory
sourceanalyzer Example.java –rules CustomRules.xml –f Report.fpr
- runs the sourceanalyzer on Example.java using the custom rulepackCustomRules.xml and creates a report named Report.fpr
sourceanalyzer Example.java –findbugs –html-report
-runs the source analyzer and the findbugs application on Example.javaand creates an html report
Source Code Analyzer OutputThe source code analyzer prints out a set of data for each issuediscovered in the source code.
Structural issues (caused due to the layout of the program and how it is written):
System information leak vulnerability
Value never read – Poor programming style
Empty password initialization vulnerability
Hardcoded password vulnerability
Dataflow issues (caused due to the data input or generated during the program): Path manipulation vulnerability
Control flow issues (caused due to the control flow of the program at run-time): Unreleased resource stream vulnerability
Semantic issues (caused due to the variations in the context – reading a line, word, etc, at which the program is run): Denial of service vulnerability
Semantic Issue Output
The output for a semantic issue follows the format:[# : Severity : Vulnerability Category : Vulnerability Subcategory : Analyzer]
Filename ( Line Number ) : Vulnerable Method
An example of this is:[831A38F81AC0FB : medium : System Information Leak : semantic]
Example.java(58) : Throwable.printStackTrace()
(in this case, the System Information Leak does not have a subcategory)
This issue is the result of calling an exception’s printStackTrace() method which will print out information about the call stack causing the error. Making this information available is generally not a good idea, as it may give an attacker information about the system.
Dataflow Issue Output
The output for a dataflow issue follows the format:[ # : Severity : Vulnerability Category : Analyzer ]
Filename ( Line Number ) : -> SinkFilename ( Line Number ) : <=> Pass-ThroughFilename ( Line Number ) : <- Source
An example of this is:[B81E3811678D1 : high : SQL Injection : dataflow ]
Example.java (38) : -> Statement.executeUpdate(0)Example.java (24) : <=> (this.query)Example.java (24) : <- ServletRequest.getParameter(return)
This issue is the result of data being taken directly from the input at line 24 (source), being placed in a query at line 24 (pass-through) and being executed as-is at line 38 (sink). The data was not sanitized at any time between being taken from the input and being executed, which leaves the system vulnerable to SQL injection attacks.
Control Flow Issue Output
The output for a control flow issue follows the format:[ # : Severity : Vulnerability Category : Analyzer ]
Filename ( Line Number ) : Start State : End State : Transition Expression
Filename ( Line Number ) : Start State : End State : Transition Expression
An example of this is:[5838DC1A38B : medium : Unreleased Resource : control flow ]
Example.java (15) : start -> connection : conn = getConnection(…)
Example.java (32) : connection -> end_of_scope : #end_scope(conn)
This issue is a result of a resource (conn) being allocated but never released. At line 15, conn goes from the start state to the connection state. At line 32, conn goes from the connection state to the end_of_scope state, because it has reached the end of its scope, but the resource was not released before the object disappeared.
Structural Issue Output
The output for a structural issue follows the format:[ # : Severity : Vulnerability Category : Vulnerability Subcategory : Analyzer ]
Filename ( Line Number )Field Declaration
An example of this is:[389A95C0581E : high : Password Management : Empty Password : structural ]
Example.java (18)Variable: password [Example.java (18)]
This issue is the result of a string variable named “password” being created as an empty string (String password = “”;). It is not a good idea to allow password strings to start out empty. It would be better to use (String password;) and wait to create the string until it was actually needed.
Audit Workbench
The Audit Workbench can be started either
by selecting it from the start menu (Windows) or by typing “auditworkbench” at
the command-line (Windows or Linux).
Audit Workbench
One convenient feature of the Audit Workbench is the ability to turn warnings on or off for specific types of issues using the AuditGuide.
The AuditGuide displays a number of types of issues in a menu on the left side of the screen, and any of these can be turned off or on by selecting “Suppress issues…” or “Warn me about …”, respectively.
Audit Workbench
Audit Workbench
The Audit Workbench also contains a built-in
editor so that issues may be dealt with and corrected from inside the program.
Audit Workbench
Audit Workbench
The Audit Workbench also allows you to
create a report about the audit and save it as any of several file types (.doc, .html, .xml,
and more).
Audit Workbench
Excerpt of a
.html report
created by
Audit Workbench
Fortify SCA
Exercise 1
Exercise 1
In this exercise you will use the command-
line “sourceanalyzer” tool to analyze a source-code file and learn about the types of
issues it generates.
Step 1
Navigate to the folder “SCAExample1” on
your computer and open it. You should see a file named “SCAExample1.java”.
Step 1
Step 2
Open a new command prompt (Windows) or
terminal window (Linux) and navigate to the SCAExample1 folder.
Step 2
Step 3
Run the source code analyzer on the file
“SCAExample1.java” using only the default settings by typing:
sourceanalyzer SCAExample1.java
and pressing enter.
Step 3
Step 4
When the sourceanalyzer application
finishes, you should have a list of warnings about problems with the code.
Step 4
Exercise Questions
1. How many issues did the sourceanalyzer tool return for SCAExample1.java?
2. What is the severity of the Password Management issues?
3. On what line of the source code file does the first Poor Logging Practice issue occur?
4. What type of issue is a System Information Leak?
Fortify SCA
Exercise 2
Exercise 2
In this exercise, you will build upon what you have
learned in Exercise 1. You will use the command-line “sourceanalyzer” tool to analyze several source-code files and create a report.
You will then use the Audit Workbench to analyze the report and make changes to the source-code.
Step 1
Locate the directory named SCAExample2
which contains the files
•UserApp.java,
•User.java, and
•userdata.dat
Step 1
Step 2
Open a command-prompt window
(Windows) or a terminal window (Linux) and navigate to the SCAExample2 folder.
Step 2
Step 3
At the command prompt, type:
sourceanalyzer *.java –f results.fpr
and press enter. When the application has completed, you will not see any output (it has been stored in the results.fprfile).
Note: Instead of *.java, you can just type the name of the java file (for example: example.java) to analyze
Step 3
Step 4
When the sourceanalyzer application has
completed, type:
auditworkbench
and press enter. This should start the
Fortify Audit Workbench application.
Step 4
Step 5
When the Audit Workbench opens, navigate
to the SCAExample2 folder and select “results.fpr” to open.
Step 5
Step 6
When the results have loaded, review the
project summary and click “Continue to Auditguide > >”.
Step 6
Step 7
The AuditGuide will allow us to specify which types of issues we are concerned with. To ignore an issue, select the issue from the list on the left and change the selected option button to “Suppress issues…”
We will not be concerned with Heap Inspection Attacks or Database Inputs, so suppress these two types of warnings by selecting “Suppress …” for each one and then clicking “OK”
Step 7
Step 8
On the left-side you will see several issue
severity levels:
•Hot
•Warning
•Info
Click on each of these buttons to view the
issues in that severity category.
Step 8
Step 9
Select the “Info” (yellow) category of issues.
Then select the “Password Management: Password in Comment” issue.
Selecting the instance of the issue in SCAExample2.java on line 34 should open SCAExample2.java in the editor window and highlight where the issue occurs (line 34).
Step 9
Step 10
A description of the issue, and example of its use and suggestions for resolving the issue are located in the Details box at the bottom.
Reading the information in this box tells us that passwords should not be stored in source-code comments like they are in our program.
To resolve this issue, remove line 34 from SCAExample2.java (you can do this in the editor window).
Step 10
Step 11
Repeat Steps 9 and 10 to learn about and resolve the remaining issues. For some issues, there may be several ways to resolve them.
Note: In order for the line numbers of the issues to point to the correct lines, any time you remove a line of code, make sure that it is replaced with a blank line. This will ensure that the line numbers of the rest of the code do not change.
Do not attempt to resolve the “Poor Logging Practice: Use of a System Output Stream” issue.
Step 12
When you have completed addressing the remaining issues, close Audit Workbench.
When prompted to save your work, click “Yes.”
Now return to your command-prompt (or terminal) window and enter the command:sourceanalyzer *.java
If you have successfully addressed all the issues, the only issues that will be displayed are those related to the “Use of System Output Stream”. If not, re-open the Audit Workbench and try again.