Appendix A. Fortify Source Code Analysis Suite Tutorial[1]

A special demonstration version of the Fortify Source Code Analysis product is included with this book. Please note that the demonstration software includes only a subset of the functionality offered by the Source Code Analysis Suite. For example, this demonstration version scans for buffer overflow and SQL injection vulnerabilities but does not scan for cross-site scripting or access control vulnerabilities.

The key you will need to unlock the demo on the CD is FSDMOBEBESHIPFSDMO. To prevent any confusion, this key is composed of letters exclusively. There are no numbers.

This tutorial presents a set of lessons that cover a number of different source code analysis topics. Each lesson builds on the knowledge gained in the previous lessons, so the lessons should be taken on in the order they are presented. The final lesson allows you to practice what you have learned using a set of open source code bases.

The tutorial provides an introduction to the Fortify Source Code Analysis Suite for Java, C/C++ (using gcc), and .NET projects (using Visual Studio). Specifically, we include information about how to use the Fortify Source Code Analysis Engine and the Fortify Audit Workbench (see Chapter 4).

There are nine lessons in this tutorial:

  1. Introducing the Audit Workbench

  2. Auditing Source Code Manually

  3. Ensuring a Working Build Environment

  4. Running the Source Code Analysis Engine

  5. Exploring the Basic SCA Engine Command Line Arguments

  6. Understanding Raw Analysis Results

  7. Integrating with an Automated Build Process

  8. Using the Audit Workbench

  9. Auditing Open Source Applications

By using this tutorial, you will learn how to audit programs for security in order to ferret out the kinds of vulnerabilities that cause real security problems. The kinds of problems that you can find are exactly like those uncovered and publicized by experienced security researchers and malicious hackers—sometimes becoming major news events. Who knows, you may even find yourself discovering previously unknown vulnerabilities in open source code that has been fielded for years!

The directories containing the files used in this tutorial are located in the Install_Directory/Tutorial directory, where Install_Directory is the directory in which the Fortify Source Code Analysis Suite is installed. See the CD accompanying this book.

Introducing the Audit Workbench

This exercise examines the results of a successful source code security audit of the Washington University FTP daemon wu-ftpd version 2.6.0 that was performed using the Enterprise version of Fortify Software. In this exercise, you use the Audit Workbench to explore a results file that was generated by the Source Code Analysis Engine and annotated by a code auditor.

The files for this lesson are located in the following directory:

Install_Directory/Tutorial/understand_AWB

  1. Start Audit Workbench and load the audit.

    • Start Audit Workbench:

      • On Windows, navigate from the Start menu as follows: Start → All Programs → Fortify Software → Fortify SCA Suite 3.1.1—Demonstration Edition → Audit Workbench.

      • On UNIX, enter auditworkbench at a command prompt.

    • Choose the Continue Audit option.

    • Select the wu-ftpd.fpr file.

  2. Examine the information displayed in the Project Summary dialog. Click Skip AuditGuide to close the Project Summary.

  3. Examine the information displayed in the navigation tree in the Navigator panel.

    • Expand the items in the tree to see the individual issues.

    • Click on the issues to see how the panels are populated for each issue. For example, notice that the Analyzer Trace panel shows data flow information when the issue is related to issues identified by the Data Flow Analyzer.

    • Examine the Summary and Detail panels for information about the issues.

    • Click the Hotlist, Warnings, and Info buttons to see how the issues are grouped by severity level.

    • Select different options in the “Group by” drop-down list to see the issues in the navigation tree grouped by file name, sink, source, taint flag, or category and analyzer (the default).

    • Locate and select the following issue: ftpd.c:5290 (Format String).

  4. Examine an issue.

    • Read the auditor’s comments concerning the issue in the Summary panel and note the settings for the analysis, status, impact, and severity buckets that the auditor has selected for the issue. In this case, the auditor considers the issue to be a remotely exploitable problem that could lead to a root compromise.

    • Click on the four code lines displayed in the Analysis Trace panel to see how the SCA Engine traced the malicious data through the program.

    • Examine the Details panel to read more about auditing format string problems.

  5. Explore other issues.

    • Click the Hotlist, Warning, and Info buttons to explore some of the other buckets.

    • Explore some of the other categories and the issues they contain for an overview of the types of problems that Fortify Software finds in C and C++ programs.

  6. Generate an audit report.

    • Select Generate Report from the Tools menu to generate a report.

    • Select Formatted Text from the “Export As” drop-down list.

    • Read the summary sections at the top of the report and some of the detailed findings that follow.

    • Click Cancel to return to the main audit view.

Exercises for the Reader

Beginner

  1. How many categories of security vulnerabilities are listed for this application?

  2. Starting with buffer overflow, how many vulnerability categories can you name?

  3. In your company, what categories of security vulnerabilities are most critical?

  4. Can you think of (or write) a line of code that would be acceptable in one program but would cause a serious security problem in another program?

Advanced

  1. Describe a scenario in which a security issue that is not currently exploitable can become a critical security issue in the future.

  2. What are some common reasons that developers introduce security vulnerabilities?

  3. What makes one security issue more important than another? How do you determine the importance of a security issue?

  4. Once you have identified and corrected all exploitable security issues, what are the arguments for and against addressing nonexploitable security issues?

Auditing Source Code Manually

This exercise introduces the goals of auditing source code for security and spells out the steps involved in performing a basic audit.

Any kind of manual source code review requires patience, an eye for detail, and extensive knowledge about the types of problems that can cause a program to fail. A security audit is no different, but instead of thinking “what could go wrong?” the auditor must consider “what could an attacker force to go wrong?” The auditor’s role is to pare down this infinite search space and identify the most dangerous problems and weaknesses in a program. Experience is invaluable but can only be gained through practice.

This exercise demonstrates a simple manual audit process for a small Web application. The files for this lesson are located under two subdirectories in the following directory: Install_Directory/Tutorial/do_manual_audit. The webapp subdirectory contains a sample Web application for this lesson. The Answers subdirectory contains responses to the questions posed below.

  1. Examine the webapp application. Do not look for specific issues yet, just become familiar with the application by asking the same types of questions that an auditor starting a code audit would ask, such as:

    • How large is the application?

    • What are the technologies involved?

    • What is the basic design of the application?

    • Who are the likely attackers?

    • What would an attacker hope to achieve?

    • How are the developers trying to protect the application?

    • What sorts of techniques might an attacker use to subvert the application?

    • What risks would a successful attack pose to the company (e.g., customer confidence, public image, etc.)?

    Some vulnerabilities are easier to spot than others. Generally speaking, when the scope of an issue is limited to a single screen of source code, it is much easier to find than an issue that requires understanding the interaction between pieces of code from multiple (far-flung) locations.

  2. Examine the source code of the following Servlet: webapp/src/java/com/simpleco/CountServlet.java.

    • How and when is this code executed?

    • What can an attacker control?

    • Can an attacker violate the programmer’s assumptions?

    • What is vulnerable about this Servlet?

  3. Examine each of the application files, consider the interaction between the various modules, and identify issues that render the application vulnerable.

Exercises for the Reader

Beginner

  1. How many vulnerability patterns can you consciously look for as you are manually auditing the code—5, 10, 100, 1,000?

  2. What techniques would you use to keep track of paths across files?

  3. How often should a security audit be performed? If you performed an audit today and fixed the problems, what would your confidence be in the code 90, 120, or 180 days later? How much new code would your developers write in 90, 120, or 180 days?

Advanced

  1. If you had to set up a process for manually auditing code in your company, how would you estimate the amount of effort and time required to do it effectively? How do the requirements scale as the size of the code base grows?

  2. What are the ideal skills for a security code auditor? How many people in your organization are well qualified? What jobs do they do today?

  3. Why do people perform security code audits rather than simply testing the software?

  4. If you cannot audit all of the code, how should you choose which section of code to audit? How confident are you about the results of the audit?

  5. Enumerate five programming styles or techniques that make auditing easier or harder.

Ensuring a Working Build Environment

To make it easy to integrate the Source Code Analysis Engine into your environment, the SCA Engine uses the same conventions as the tools you use to compile and build the application. The purpose of this exercise is to ensure that you are comfortable within your existing build environment before you attempt to integrate source analysis.

For analyzing C and C++ programs, ensure that there is a compiler supported by Fortify Software installed on your computer. (See the README.txt on the CD for a list of supported compilers.)

This exercise assumes that you are using gcc to compile C and C++. If you are using Windows and have not yet installed a supported compiler (such as Microsoft cl), you can install gcc as part of Cygwin <http://www.cygwin.com/>.

Depending on how you typically build your project, it is likely that you will also need a build tool, such as make or ant, installed on your computer.

Typical compilers and linkers search for and resolve certain symbols when building a working program. The SCA Engine is similar to a “security compiler” that operates on the source code base. As such, the SCA Engine functions optimally when it can resolve all of the symbols found in the program.

The more code you analyze, the more comprehensive the results will be. C, C++, and .NET projects must compile completely in order for the SCA Engine to analyze them successfully. However, the architecture of the SCA Engine does make it capable of analyzing individual or incomplete Java files if you choose to do so—albeit at the cost of reduced accuracy due to the unresolved symbols.

  1. Verify that you can compile a simple program without any errors.

    • For C and C++ source code:

      • Change to the following directory:

        Install_Directory/Samples/basic/stackbuffer

      • Enter the following command:

        gcc stackbuffer.c

    • For Java source code:

      • Change to the following directory:

        Install_Directory/Samples/basic/eightball

      • Enter the following command:

        javac EightBall.java

    • For .NET projects:

      • Open the following file in Visual Studio .NET:

        Install_DirectorySamplesadvancedcsharpSample1
Sample1.sln

      • Verify that the project is configured to build in debug mode.

      • Choose Rebuild Solution from the Build menu.

  2. Ensure that you can successfully build the project that you plan to use for source code analysis.

    • For C and C++ projects, you typically run the make or nmake utility.

    • For Java projects, you typically use ant.

    • For .NET projects, you typically use Visual Studio.

Running the Source Code Analysis Engine

This exercise introduces the Source Code Analysis Engine. You will verify that the SCA Engine is properly installed and analyze a few small programs.

  1. Run an analysis on a single source file:

    • For C and C++ source code:

      • Change to the following directory:

        Install_Directory/Samples/basic/stackbuffer

      • Enter the following command:

        sourceanalyzer gcc stackbuffer.c

      • Compare the output with the expected results given at the end of this exercise.

    • For Java source code:

      • Change to the following directory:

        Install_Directory/Samples/basic/eightball

      • Enter the following command:

        sourceanalyzer EightBall.java

      • Compare the output with the expected results given at the end of this exercise.

    • For .NET code:

      • Change to the following directory:

        Install_DirectorySamplesadvancedcsharpSample1

      • Enter the following command:

        sourceanalyzer Sample1.exe

      • Compare the output with the expected results given at the end of this exercise.

Analysis Results of stackbuffer.c

The following output shows the results of an analysis of stackbuffer.c:

[Install_DirectorySamplesasicstackbuffer]

[BB73F23E46159FBE5ED3C1968C046828 : low : Unchecked Return Value : semantic ]
stackbuffer.c(13) : read()

[EDACF5BD763B329C8EE8AA50F8C53D08 : high : Buffer Overflow : data flow ]
stackbuffer.c(4) : -> memcpy(2)
    stackbuffer.c(17) : -> doMemCpy(2)
    stackbuffer.c(15) : <- scanf(1)

Analysis Results of Eightball.java

The following output shows the results of an analysis of EightBall.java:

[Install_DirectorySamplesasiceightball]

[F7A138CDE5235351F6A4405BA4AD7C53 : low : Unchecked Return Value : semantic ]
EightBall.java(12) : Reader.read()

[EFE997D3683DC384056FA40F6C7BD0E8 : medium : Resource Injection : data flow ]
EightBall.java(12) : -> new FileReader(0)
    EightBall.java(8) : <=> (filename)
    EightBall.java(8) : <-> Integer.parseInt(0->return)
    EightBall.java(6) : <=> (filename)
    EightBall.java(4) : -> EightBall.main(0)

[397D4B4A4FF20A0C13369B1D47844C53 : medium : Unreleased Resource : control flow ]
    EightBall.java(12) : start -> loaded : <inline expression>.new FileReader(...)
    EightBall.java(14) : loaded -> end_of_scope : #end_scope(<inline expression>)

Analysis Results of Sample1.exe

The following output shows the results of an analysis of Sample1.exe. Note: Sample1.exe was generated in the “Ensuring a Working Build Environment” section.

[Install_DirectorySamplesadvancedcsharpSample1]

[C0EB5C44F4E926C3748984B3C4B869A5 : high : SQL Injection : data flow ]
Sample1/Class1.cs(29) : -> new SqlDataAdapter(0)
    Sample1/Class1.cs(19) : -> Sample1.Main(0)

[3CC21A4EF4179833409BEC57C9420379 : high : SQL Injection : data flow ]
Sample1/Class1.cs(31) : -> new SqlDataAdapter(0)
    Sample1/Class1.cs(20) : <=> (tainted_query)
    Sample1/Class1.cs(20) : <-> String.Concat(1->return)
    Sample1/Class1.cs(20) : <-> String.Clone(this->return)
    Sample1/Class1.cs(19) : ->  Sample1.Main(0)

[8A25799D696115E0FD031CB294454B84 : medium : Unreleased Resource : control flow ]
    Sample1/Class1.cs(24) : start -> loaded : conn.Open(. . .)
    Sample1/Class1.cs(39) : loaded -> end_of_scope : #end_scope(conn)

Exercises for the Reader

Beginner

  1. What are the benefits of integrating the SCA Engine into your environment as a compiler?

  2. Why must you specify a compiler for C/C++ code but not for Java or .NET code?

  3. Where is the log file used by the SCA Engine?

Advanced

  1. If the SCA Engine cannot find some of the files for the software being built, what information is missing? Consider header files and source files. How will the missing information affect the results?

  2. How do you know whether or not the SCA Engine was able to find and read all of the required files?

Exploring the Basic SCA Engine Command Line Arguments

This exercise continues the introduction of the Source Code Analysis Engine. In this exercise, you will experiment with the basic command line arguments accepted by the SCA Engine.

  1. Consider the command line syntax:

    • For C and C++ source code, the syntax is:

      sourceanalyzer [options] compiler [compiler-flags]
files

    • For Java source code, the syntax is:

      sourceanalyzer -cp classpath [options] files

    • For a .NET executable, the syntax is:

      sourceanalyzer [options] –libdirs dirs executable

  2. Experiment with the following basic command line arguments using the sample programs from the previous exercise.

    • Compiler:

      For C and C++ code, the sourceanalyzer command is included in the compile line as a prefix to the actual build command, such as gcc or cl. For complex builds, the sourceanalyzer command is also used to intercept archiving commands, such as ar, and linking commands, such as link and ld. The SCA Engine interprets the flags passed in to the build command and adjusts its own operation accordingly, without affecting the actual build.

      For Java code, the compiler is implicitly javac.

    • Output Format: -format format

      This option specifies the output format. The default format is text. To select the Fortify Vulnerability Description Language (FVDL) format, which is the Fortify Software XML-based vulnerability description language, specify -format fvdl. You can also specify fvdl-zip, which produces a zipped FVDL file. FVDL is more verbose than text and is used by the Fortify Audit Workbench and other tools.

    • Output Location: -f filename

      This option specifies a file location to which the output will be written. By default, if a file location is not specified, the output is written to the console.

For a detailed description of the command line syntax and options supported by the SCA Engine, see the following topics in the Source Code Analysis Engine User’s Guide:

  • “Using Source Code Analysis Engine from the Command Line”

  • “Using Source Code Analysis Engine Command Line Options”

The Source Code Analysis Engine User’s Guide is located at:

Install_Directory/Documentation/SCA/index.htm

The next lesson, “Understanding Raw Analysis Results,” explains how to interpret the results produced by the SCA Engine.

Exercises for the Reader

Beginner

  1. If a single source code base is used to build multiple executable programs, how can you use the SCA Engine to evaluate the programs independently?

Understanding Raw Analysis Results

This exercise describes the Source Code Analysis Engine output. You will examine the different output formats and contents generated by the various analyzers.

The SCA Engine produces two primary output formats: text and FVDL. The text format is human-readable and is designed for quick scans and easy verification of results. FVDL is an XML format that is consumed by Audit Workbench and other tools.

  • The Java source file for this lesson is:

    Tutorial/understand_results/StringSearch.java

  • The expected output from the SCA Engine is located in:

    Install_Directory/Tutorial/understand_results/Answers

    1. Examine the text output format. Run the SCA Engine on StringSearch.java as follows:

      sourceanalyzer StringSearch.java

      The output shows three issues.

      Issue 1

      [C9FE6AF8A29314E2DC22F0E9191802F8 : low : Unchecked Return Value : semantic ]
   StringSearch.java(18) : FileInputStream.read(0)

      Issue 2

      [2AE729678F97328125F563C53BEB1524 : medium : Resource Injection : data flow ]
   StringSearch.java(16) :  -> new FileInputStream(0)
   StringSearch.java(14) : <=> (searchIn)
   StringSearch.java(6)  :  -> StringSearch.main(0)

      Issue 3

      [3A8FE7972DB6C28956AC54DF8E63424D : medium : Unreleased Resource : control flow ]
   StringSearch.java(16) : start -> loaded : fos.new FileInputStream(...)
   StringSearch.java(21) : loaded -> end_of_scope : #end_scope(fos)

      The first line of the text output is the common root directory of all the files that have reported vulnerabilities, such as:

      [/opt/FortifySoftware/SCAS3.1-EE/Tutorial/understand_results]

      The first line of each issue has the following format:

      [Instance ID : severity : category : analyzer ]

      For example, Issue 1 reports that on line 18 in the StringSearch.java file, the return value of FileInputStream.read() is not checked. The issue details also indicate that this was detected by the Semantic Analyzer and that, by default, it was assigned the severity low.

      If the SCA Engine has more information about a particular issue, it includes the information on subsequent lines.

      For example, Issue 2 reports that line 16 in StringSearch.java contains a potential resource injection vulnerability that could allow an attacker to control a resource used by the application. The subsequent lines of output show that the value, potentially controlled by an attacker, enters the program at line 6 as the first argument to StringSearch.main(). This issue is identified by the Data Flow Analyzer and assigned a medium risk.

      Values that cause data flow issues can pass through several hops between where they enter the program and the point at which the program uses the data as part of a sensitive operation.

      The Control Flow Analyzer can also provide additional information about an issue. Issue 3 reports that the resource created on line 16 was not properly released before it went out of scope. In other words, the code fails to call close() on the resource.

    2. Rerun the analysis engine, this time producing FVDL output. Use the -format option to create the FVDL and the -f option to send the output to an XML results file, as follows:

      sourceanalyzer -format fvdl -f results.fvdl
StringSearch.java

    3. Open and inspect results.fvdl in a text editor. Note that it contains all of the information found in the text output, plus the following information in the preamble:

      • Date and time of the analysis.

      • Number of lines of code analyzed.

        Note also that the first issue corresponds to the first issue in the text output. It has the same information regarding location and category, plus it shows the unique identifier for the vulnerability class. The vulnerability class identifier references a description of the vulnerability class, located at the end of the FVDL file. The unique instance ID unambiguously refers to this vulnerability.

Exercises for the Reader

Beginner

  1. How many of the Fortify vulnerability categories can you describe in detail?

Advanced

  1. Write a piece of code containing an issue that is identified by each of the different analyzers.

  2. Give an example in which a single issue will be found more than once.

  3. Give an example in which a single issue will be found by more than one analyzer.

  4. What is the cost of being wrong about an issue (that is, calling a finding a vulnerability when it is not, and calling a finding benign when it is a vulnerability)?

Integrating with an Automated Build Process

This exercise demonstrates how to integrate the Source Code Analysis Engine with an existing build process.

  • For C and C++ code, build processes typically use some form of the make utility, such as gmake or nmake, and a project-specific Makefile to build the project.

  • For Java code, projects are typically built using the ant utility and a build.xml file.

The SCA Engine mirrors the way the compiler processes the source code of an application. This means that source code that is excluded due to conditional compilation (#ifdef) and code that is not included in the build is automatically excluded by the SCA Engine. Thus, extraneous and misleading results that are not part of the actual application are avoided.[2]

Integrating with a Makefile

  1. Edit a Makefile to invoke the SCA Engine during the build process. An easy way to cause a Makefile to invoke the SCA Engine is to locate the CC variable in the Makefile and insert the sourceanalyzer command and any options before the actual compiler name. Consider the following Makefile segment:

    6:  #### Tools
7:
8:  CC = gcc
9:  AR = ar sr
10: LINK = ld
11:
12: #### Options

    The following shows the addition of the SCA Engine to the Makefile:

    5:  #### Tools: introduced sourceanalyzer command and
6:  #### buildid/projectid=345
7:
8:  CC = sourceanalyzer -b 345 -c gcc
9:  AR = sourceanalyzer -b 345 -c ar sr
10: LINK = sourceanalyzer -b 345 -c ld
11:
12: #### Options

    The command line options specify the following:

    • -b specifies the build ID, in this case 345.

    • -c specifies that the SCA Engine runs the compiler as well as performs the translation.

    This modified Makefile causes the SCA Engine to generate an intermediate security representation of the source files and the dependencies of the build process. It also invokes the compiler and build commands so that there is no interference with the regular build output. However, actual security analysis is performed as a separate step.

  2. Run the build as you normally would, but follow it with a command to perform the security analysis with a reference to the build ID:

    make; sourceanalyzer -scan -b 345 -f /bld/results.fvdl -format fvdl

    The command line options specify the following:

    • -scan specifies that the SCA Engine should perform an analysis on the provided build ID.

    • -b specifies the build ID, in this case 345.

    • -f specifies the file to which the results are written.

    • -format controls the output format (fvdl, fvld-zip, or text).

    The output file is specified as an absolute path because most make projects enter and exit various directories during the build, and compilations that occur in each directory create their own output files. If you specify an absolute path for the output file, all results for the make are generated in one FVDL file.

    If an output file with the same name already exists and the -append option is specified, the output is appended to the existing file. If the -append option is not included, the existing results are overwritten. To keep data from different analysis runs separately identifiable, rename or delete the output file before running each make.

  3. To see the details, including resolution suggestions, open the results.fvdl file in Audit Workbench.

Integrating with an ant Build File

  1. Ensure that the Install_Directory is included in the PATH environment variable.

  2. Add the following to either ant’s lib directory or to your CLASSPATH:

    Install_Directory/Core/lib/sourceanalyzer.jar

    Note: In ant 1.6 and above, it is also possible to pass the path to sourceanalyzer.jar on the command line through the -lib parameter.

    • Set the build.compiler property using either the command line or the property tag.

    The command line syntax is:

    >$ant -Dbuild.compiler="com.fortify.dev.ant.SCACompiler"
-Dsourceanalyzer.buildid=Build_ID

    The property tag syntax is:

    <property name="build.compiler" value="com.fortify.dev.ant.SCACompiler"/>
<property name="sourceanalyzer.buildid" value="Build_ID"/>

    Tip: When build files are used on systems without the SCA Engine, use the ant <available> task to define build.compiler:

    <available classname="com.fortify.dev.ant.SCACompiler"
property="build.compiler" value="com.fortify.dev.ant.SCACompiler"/>

  3. Perform the following steps to use the sourceanalyzer task to select files to be scanned or to run analysis. Include a typedef for the task in the build file as follows:

    <typedef name="sourceanalyzer"
classname="com.fortify.dev.ant.SourceanalyzerTask"/>

    You can now include the sourceanalyzer task in any target.

  4. Specify parameters, or define attributes in nested elements for the sourceanalyzer task. Valid parameters are listed in the Source Code Analysis Engine User’s Guide.

The following is an example of running ant from the command line:

>$ ant -Dcom.fortify.dev.ant.SCACompiler.args="  -f resultsFile.fvdl
       -format fvdl"

The following is an example of modifying the build.xml sourceanalyzer task:

<sourceanalyzer buildid="${sourceanalyzer.buildid}"
           scan="true"
           resultsfile="results_file.fvdl"
           format="fvdl"
           rules="rules_file.xml"
           filter="filter_file.xml" />

Advanced Command Line Syntax for Java

Using the command line syntax for Java makes it easy to scan Java and J2EE code bases. In many cases, a J2EE project can be accurately analyzed without integrating with the build process. The syntax is:

sourceanalyzer -cp classpath [options] srcfile-specifier1 srcfile-specifier2 ...

For example, the following command invokes the analysis of the source code of a typical Web-based J2EE application:

sourceanalyzer -cp "app_directoryWEB-INFlib*.jar;app_directoryWEB-INFclasses"
               -f results.fvdl -format fvdl .

Note: The dot at the end of the statement specifies the current directory.

Run the preceding command from the directory where the build.xml file is located. In this case it is assumed that the source files are located in a directory that is below the current directory. If the source files are located in a different location, use that as the srcfile-specifier instead of the current directory.

If there are multiple jar file directories under WEB-INF, you can also specify the following as part of the classpath: "app_directoryWEB-INF***.jar"

Exercises for the Reader

  1. How often do you do a build? How often do you perform system tests? What are the benefits of doing a security analysis with every build?

  2. Assuming you cannot review the results from sourceanalyzer every time you build, how can you use the information that comes from sourceanalyzer in each build?

Using the Audit Workbench

This exercise describes how to use the Audit Workbench to review results obtained from the Source Code Analysis Engine and generate audit reports based on those results.

The J2EE application for this lesson is located at Tutorial/use_AWB/webapp.

The SCA Engine has already analyzed the source code, and the FVDL output is located at Tutorial/use_AWB/webapp.fvdl file.

  1. Start the Audit Workbench.

    • For Window systems, select Start → All Programs → Fortify Software → Fortify SCA Suite 3.1.1—Demonstration Edition → Audit Workbench.

    • For UNIX systems, if your installation directory is on the path, enter auditworkbench on the command line; otherwise enter the fully qualified path to Audit Workbench.

  2. Select the New Audit option.

  3. Select and load the following file: Tutorial/use_AWB/webapp.fvdl

  4. Name the new project “SimpleCo Web Application.”

  5. Examine the information in the Project Summary dialog box.

  6. Click Continue to AuditGuide >> and answer the questions that follow. When you are finished, AuditGuide limits the issues that Audit Workbench displays to the ones that are relevant to the application being audited.

  7. Examine the information in the Navigator panel.

    • The three severity buttons, Hotlist, Warnings, and Info, display the number of detected issues for each severity type and control the contents of the navigation tree.

    • The items that appear in the navigation tree vary according to which “Group by” option is selected.

    • When expanded, the navigation tree lists the files in which issues were detected and the vulnerability categories.

    • The pair of numbers in square brackets shown next to each item in the expanded tree indicates how many of the issues have been audited (the number on the left) and how many issues there are total (the number on the right).

    • The “group by” feature allows you to group and display issues by category and analyzer (the default), file name, sink function, source function, and taint flag.

    • The Search field allows you to limit the displayed issues to those containing the search string.

  8. Audit the first issue.

    • Expand the first element in the LoginPkg.sql:26 navigation tree, and examine the information that populates the other panels.

      • The Source Code Viewer panel displays the section of code in LoginPkg.sql containing the issue.

      • The Analysis Trace panel in the lower left corner displays the flow of tainted data through the program.

      • The Summary panel displays the issue’s vulnerability category and location (file name and line number) and an abstract summary of the issue. It also allows you to enter comments, change status, move it to another issue bucket, specify its impact, suppress the issue, and (if integrated with a bug tracking system) file a bug.

    • Click the Details tab to examine the following information about the issue: vulnerability category, description, auditing tips, and reference.

  9. Audit the remaining issues following the same steps.

  10. Save your work. On the File menu, select Save Project.

  11. Generate and export an audit report as follows:

    • Select Generate report in the Tools menu.

    • Select Raw XML from the “Export as” drop-down menu and click OK.

    • Open the report that you exported in an XML viewer or text editor and verify that your comments and settings are present.

Exercises for the Reader

Beginner

  1. Assuming that an attacker does not have your source code, what advantages do you have in finding vulnerabilities?

  2. How do you envision feeding back vulnerabilities found in Audit Workbench to the developers who will fix them?

  3. If you only had the text output for a large project, how would you go through it without Audit Workbench?

  4. If the Source Code Analysis Engine runs on a build server but you run Audit Workbench on your local machine, will you run into problems? How will you solve them?

Advanced

  1. How many Source Code Analysis vulnerability categories can you describe in detail along with example exploitable code?

  2. What kind of comments do you tend to use most often when you are auditing?

  3. In the last 30 days, how many of these vulnerability categories have appeared on BugTraq?

  4. Name some vulnerability categories that have appeared on BugTraq that are not Fortify Source Code Analysis vulnerability categories.

  5. Do you think an external attacker viewing the program as a black box would name vulnerability categories in the same manner as an internal auditor who is analyzing the source code (white box) from the inside, or would they be different? Why?

Auditing Open Source Applications

Now you know how to use the Fortify Source Code Analysis Suite, and you are ready to embark on your own independent security audits, equipped with analysis capabilities that would have typically taken a source code auditor many years to learn. This final exercise allows you to practice using the Source Code Analysis Engine and Audit Workbench by auditing open source projects.

The following subdirectories are located at Install_Directory/Tutorial/do_open_source_audit:

  • splc—. A small J2EE application that provides a Web interface for managing inventory.

  • webgoat—. A set of Java servlets developed by the Open Web Application Security Project (OWASP) to illustrate various Web security issues.

  • wu-ftpd-2.6.0—. The Washington University FTP daemon (also used in “Introducing the Audit Workbench”).

  • Answers—. Contains subdirectories for each of the four projects listed above with notes, output, and security findings.

Note: These projects can be evaluated independently and in any order.

splc

  1. Use ant to build splc.

  2. When you are certain that the project is building correctly, add the sourceanalyzer command to the build process, perform an “ant clean,” and rebuild.

    Note: For help, see the “Integrating with an Automated Build Process” exercise.

  3. Analyze the resulting FVDL with Audit Workbench. Note that the application contains suspicious use of sockets.

  4. Compare your results to those in the Install_Directory/Tutorial/do_open_source_audit/Answers/splc directory.

webgoat

  1. Use ant to build webgoat.

  2. Once you are satisfied that the project is building correctly, add the sourceanalyzer command to the build process, perform an “ant clean,” and build again.

    Note: For help, see the “Integrating with an Automated Build Process” exercise.

  3. Analyze the resulting FVDL with Audit Workbench.

  4. Compare your results to those in the Install_Directory/Tutorial/do_open_source_audit/Answers/webgoat directory.

wu-ftpd-2.6.0

  1. Use the configure command to create a makefile for wu-ftpd. You may need to add options to the configure command, as in the following example:

    ./configure -host localhost --disable-dns

  2. Build wu-ftpd using the make utility.

  3. When you are certain that the project is building correctly, add the sourceanalyzer command to the build process.

    Note: For help, see the “Integrating with an Automated Build Process” exercise.

    Rerun the configure command, as follows:

    rm config.cache config.h config.log config.status
CC="sourceanalyzer -b wu-ftpd -c gcc"
./configure -host localhost --disable-dns

  4. Run the SCA Engine:

    make clean
make
sourceanalyzer -scan -b wu-ftpd -format fvdl -f wu-ftpd.fvdl

  5. Analyze the results using Audit Workbench.

  6. Compare your results to those located at Install_Directory/Tutorial/do_open_source_audit/Answers/wu-ftpd-2.6.0.

    Note: This demo does not utilize the full set of rules, therefore your output will contain only summary results in some cases.

Exercises for the Reader

Advanced

  1. Return to the first lesson, “Introducing the Audit Workbench,” and locate the Buffer Overflow in the wu-ftpd-2.6.0 file using the SCA Engine and Audit Workbench.

  2. What other methods for identifying security vulnerabilities can you name? How do they overlap or complement source code analysis?

Answers

For answers to the questions in this tutorial, see this book’s Web site at <http://www.swsec.com>.


[1] This appendix was created and is maintained by Fortify Software and is reprinted here with permission.

[2] And problems not found in one build path but found in another can slip by auditors.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.139.97.202