With AppScan Source trace, you can verify input validation and encoding that meets your software security policies. You can look at the findings that produce input/output traces and mark methods as validation and encoding routines, sources or sinks, callbacks, or taint propagators.
AppScan Source traces the flow of data through an application, across modules and languages. It displays the paths of potentially dangerous data in a call graph, indicating areas where an application may be susceptible to vulnerabilities.
Tracing helps you defeat SQL Injection, cross-site scripting, and other input validation attacks by identifying the lack of approved input validation and encoding routines in applications. You interactively trace the entire call graph, clicking directly from the Trace view to see the source in the development environment or code editor of your choice. Tracing also enables policy
enforcement, allowing you to identify approved routines required for proper input validation and encoding, taint propagation, or sinks and sources, and include them in future scans.
When a scan results in a trace, you can create input validation or encoding routines, vulnerabilities, sinks, sources, or taint propagators for specific findings from the Trace view. For example, if you mark a routine as a validation routine in AppScan Source for Analysis and add it to the AppScan Source Security
Knowledgebase, subsequent scans no longer report Validation.Required or Validation.Encoding.Requiredfindings for data paths on which the routines are called. In the Trace view, you can also define vulnerabilities as a source, sink, or both - and identify a method as a taint propagator, a tainted callback, or not being susceptible to taint.
AppScan Source trace scan results
Scan results may include traces identified by AppScan Source trace. The icon in the Tracecolumn indicates the existence of a trace of the call graph.
Scans may generate findings of type Validation.Required and
Validation.EncodingRequired. These findings indicate a location in the source code where data is read from an external source or saved to an external sink. The scan
flags these cases because the data should be validated or encoded to prevent malicious or erroneous data from doing harm.
Validation and encoding
Validation is the process of checking input data to ensure that it is well-formed. A Validation.Required finding indicates that no validation occurred along a given data path from source to sink. Validation can be as simple as bounding the data to a maximum length and as complex as checking for well-formed names and addresses. Validation can also check for attacks such as SQL Injection by detecting illegal character sequences that enable these attacks.
Encoding is the process of transforming the data into a well-formed state. A Validation.EncodingRequired finding indicates that no encoding occurred along a given data path from source to sink. Encoding could be as simple as escaping characters or as complex as encrypting the data. Encoding can also prevent attacks such as Cross-Site Scripting by escaping the characters that lead to these attacks.
When you first scan, AppScan Source may identify a finding as a suspect security finding. When you create a validation or encoding routine that applies to a specific source, AppScan Source for Analysis reports the finding as definitive (instead of suspect) if the specified validation or encoding routine is not called after it receives data from the source.
Assessments track data from known sources throughout a project. If data can be tracked from a known source to a known sink, specified validation and encoding routines can ensure that a malicious attack could not occur with unbounded input data.
Searching AppScan Source traces
If you want to group trace findings, you can search for sources or sinks. This causes the trace findings to appear in the Search Results view.
In the Trace view, click Search for traces with the same type routine. Then, in the Search Findings dialog box, select source, sink, lost sink (includes virtual lost sinks), virtual lost sink, or trace calls to isolate the results to the traces that contain the string. The search results, which are cumulative, appear in the Search Results view. From this view you can search again to refine the search.
Input/output tracing
An input/output trace is generated when AppScan Source for Analysis can track the data from a known source to a sink or lost sink.
Input/Output Trace
If the code analysis can track a tainted source to a sink or lost sink, then the analysis produces an input/output trace. The root of the trace is the method that gets data from taint-producing sources and passes it to a series of calls that eventually write to an unprotected sink.
Sources and sinks
v Source: A source is an input to the program, such as a file, servlet request, console input, or socket. For most input sources, the data returned is unbounded in terms of content and length. When an input is unchecked, it is considered tainted. Sources are listed in any findings table in the Source column.
v Sink: A sink can be any external format to which data can be written out. Sink examples include databases, files, console output, and sockets. Writing data to a sink without checking it may indicate a serious security vulnerability.
v Lost SinkA lost sink is an API method that can no longer be traced.
Note: Lost sinks do not apply to JavaScript findings.
Using the Trace view
About this task
In the Trace view, you view a single input/output trace for a finding. The pane is divided into three panels:
v Input and output stacks v Data Flow
v Graphical Call Graph
These panels are described in greater detail in “Input/output stacks in the Trace view” on page 154.
Note: In a JavaScript trace, a “JavaScript Statement Graph” on page 155 is displayed rather than a Graphical Call Graph.
To view an AppScan Source trace:
Procedure
1. Scan and find trace results in the Findings view.
2. From the View menu, open the Trace view.
3. Select the rows in the findings table that display the Trace icon. The Trace view displays the trace details.
Input/output stacks in the Trace view
The upper left panel displays the input and output stacks. The stack is a sequence of calls that terminates at either a source (input stack) or sink (output stack).
Data Flow
The lower left panel contains the data flow for the selected method. Data can flow through a method call or an assignment. The data flow section displays the line number in the source code where the item and context appear.
Call Graph
Note: In a JavaScript trace, a “JavaScript Statement Graph” on page 155 is displayed rather than a Graphical Call Graph.
The chart is a graphical representation of the call graph. Each method call is a rectangle within the graph showing the class name and the method name:
v Red identifies the method call as a source, sink, or both.
v A lost sink is an API method that can no longer be traced. A virtual lost sink is a lost sink that is also a virtual function (a function that can have more than one implementation). Yellow identifies the method call as a lost sink or virtual lost sink.
v Blue indicates that the method call is not a validation/encoding routine.
v Grey represents all other trace node types.
Each method call is divided into three sections: the class name, the method name, and the tainted argument name. Hover text for the method call provides greater detail.
Lines with arrows represent calls from method to method. An unfilled arrowhead indicates that there was no known tainted data in the call, while a solid arrow indicates tainted data flow. A dashed arrow indicates a return statement.
Symbol Description
Method call with no known tainted data
Method call with tainted data
Return with tainted data
Source (red): A method, function, or parameter that is the origin of potentially untrustworthy data.
Sink (red): A method or function that is potentially vulnerable to tainted data or is potentially dangerous to use.
Lost sink (yellow): A method/function that is potentially vulnerable to tainted data or is potentially dangerous to use.
Virtual lost sink (yellow): A type of lost sink that is resolved to more than one concrete implementation.
Not a validation/encoding routine (blue).
Marking an API as not a validation/encoding routine identifies that this API does not validate any data.
Taint propagator: A function/method that propagates taint to one or more of its parameters, to its return value, or to this pointer.
Tip:
v In the Trace view, hovering over trace nodes in the graph provides information about the node.
v The two left panels in the view (the input/output stacks panel and the data flow panel) can be collapsed for easier viewing of the graphical call graph. To
collapse these panels, select the Hide tree view arrow button. To display these panels when they are hidden, select the Show tree view arrow button.
v Move the scroll bar to zoom in and focus on details - or to zoom out to see more. Hovering over the zoom scroll bar provides the current zoom level. To zoom in to the maximum level, click Zoom to 200%. To zoom out as far as possible, click Zoom to fit.
JavaScript Statement Graph
The statement graph section of a JavaScript trace displays the data flow between statements.
Within the graph, each statement is a rectangle that provides the following information:
v The path and file name of the affected file. If the next statement is located in the same file, only the file name is listed.
v The line number that contains the statement.
v If available, the section of code that is of interest.
v If the rectangle is red, the statement is a source, sink, or both.
v If the rectangle is grey, the statement is a taint propagator.
v Hover text for the statement provides greater detail.
Lines with arrows represent data flowing from statement to statement.
Symbol Description
Flow of tainted data
Source (red): A statement that is the origin of potentially untrustworthy data.
Sink (red): A statement that is potentially vulnerable to tainted data or is potentially dangerous to use.
Taint propagator: A statement that propagates taint to one or more of its parameters, to its return value, or to this pointer.
Tip:
v In the Trace view, hovering over trace nodes in the graph provides information about the node.
v The two left panels in the view (the input/output stacks panel and the data flow panel) can be collapsed for easier viewing of the graphical call graph. To
collapse these panels, select the Hide tree view arrow button. To display these panels when they are hidden, select the Show tree view arrow button.
v Move the scroll bar to zoom in and focus on details - or to zoom out to see more. Hovering over the zoom scroll bar provides the current zoom level. To zoom in to the maximum level, click Zoom to 200%. To zoom out as far as possible, click Zoom to fit.
Analyzing source code in an editor
With AppScan Source, you can analyze or modify source code in an internal editor - or you can choose from a variety of external editors.
External editors allow you to review results in AppScan Source for Analysis and make code modifications in the development environment of your choice. External editors include:
Table 16. Supported external editors
Editor Platform
Eclipse (see the AppScan Source system requirements to learn which versions of Eclipse are supported)
Windows and Linux
Notepad Windows
vi Linux
System Default Windows and Linux
Note: You cannot edit source files in a WAR file.
To view/modify source code in the editor, choose one of these options:
v Double-click a finding in the findings table. The internal editor opens at the line of code.
v Right-click a finding in the findings table and select Open in Internal Editor or Open in External Editor> <editor> (where <editor> is one of the supported external editors listed in the above table).
v Select a trace node and then select the Open in Internal Editor or Open in External Editor> <editor> toolbar button - or right-click the selection and select Open in Internal Editoror Open in External Editor > <editor> from the menu.
If you have opened a file in the editor, markers indicate locations in the file that represent findings. To follow these back to the findings table, right-click the line of code in the editor and then select Show in Findings View from the menu.
Validation and encoding scope
From the Trace view, you can specify custom validation and encoding routines that, once stored in the AppScan Source Security Knowledgebase, marks data as checked instead of tainted. With the Custom Rules Wizard, you define these routines based on their scope.
See “Example 4: Validation in depth” on page 167 for the procedure to create validation and encoding routines.
Validation or encoding routines are based upon their scope and are defined as:
v “API specific”
v “Call site specific” on page 158
API specific
API specific validation and encoding routines may be associated with a single project or multiple projects.
API specific routines will untaint any data coming from all instances of a specific source API. For example, you could specify a validation routine for any input from the API:
javax.servlet.ServletRequest.getParameter (java.lang.string):java.lang.string
API specific routines are stored on the server. API specific routines for a project are stored in the project.
Call site specific
Call site specific routines are always associated with a single project.
Call site specific routines will untaint data coming from a specific location in the code. When you create a call site specific validation or encoding routine, you specify that the routine applies to a particular input call site. Call site specific routines are always stored in the project.
Note: Call site specific applies to any call to the validation routine within the same method.
Creating custom rules from an AppScan Source trace
You can create custom rules from the Trace view that allow you to filter out findings with traces that are taint propagators, not susceptible to taint, or sinks.
You can also mark methods in the trace as validation/encoding routines (or indicate that they are not validation/encoding routines).
About this task
See “Example 2: Creating a Validation/Encoding Routine from the Trace view” on page 162 for an example of source code, the output, and the procedure to create the validation and encoding routines.
Table 17. Valid markings for Trace view nodes
Selected method Valid marking
Intermediary nodes v Validation/encoding routines
v Not susceptible to taint
v Not a validation/encoding routine
Lost sink v Taint propagator
v Not susceptible to taint v Sink
Procedure
1. In the Trace view, right-click the method or node for which you want to create a custom rule and then choose the custom rule to create - or select the method or node and click the appropriate custom rule toolbar button. The options for marking routines and methods are:
Option Description
Mark as a Validation/Encoding routine
Mark as not a Validation/Encoding routine
Mark as a taint propagator
Mark as not susceptible to taint
Mark as a sink
Note: If there is no entry in the Trace view for the method for which you want to create a custom rule, click Launch the custom rules wizard to add a
validation routine that is not on the trace graph. In the Custom Rules Wizard, proceed to the Select Validation/Encoding Routine page. Select the validation routine and then specify the location, scope, any sources or sinks, or any properties, according to the instructions in the next step. See “Example 2:
Creating a Validation/Encoding Routine from the Custom Rules Wizard” on page 165 for details about creating a validation routine with this wizard.
2. If you are creating a custom rule that marks a method as a sink or a validation/encoding routine, you may need to make further settings:
a. If you mark the method as a sink, specify the sink attributes:
v Vulnerability Type v Severity
b. For validation routines, specify the location and scope - and any sources or sinks, or their properties, for which the validation routine should apply.
v Apply to:
– this call to <method name> (call site specific): Applies to the input just for this call.
– any call <method name> (API specific): Applies to the validation/encoding routine for any call to the method.
– <method name> not considered, all constraints specified below:
Allows all sources to be affected by the rule.
v Scope:
– Apply to this project: When selected, the rule is stored in the project (.ppf) file.
– Apply to all projects: Validation rules created with this setting are stored in the database.
v Sources: Select the input source or sources to which the validation routine should apply. To add a source, click Add and then select the
source from the Choose Signatures dialog box. To add multiple sources, you can multiselect them in the Choose Signatures dialog box.
v Sinks: Select the sink or sinks to which the validation routine should apply. To add a sink, click Add and then select the sink from the Choose Signatures dialog box. To add multiple sinks, you can multiselect them in the Choose Signatures dialog box.
v Source Properties: If you want the rule to clear traces that begin in a source with a specific property, click Add a VMAT property and then select the property from the Choose Properties dialog box. To add multiple properties, you can multiselect them in the Choose Properties dialog box.
v Sink Properties: If you want the rule to filter out traces that end in a sink with a specific property, click Add a VMAT property and then select the property from the Choose Properties dialog box. To add multiple
properties, you can multiselect them in the Choose Properties dialog box.
3. After creating custom rules in the Trace view, you must scan your code again to see the rules reflected in the findings lists and traces. Custom rules that you create in the Trace view can be viewed and deleted in the Custom Rules view.
To view details of the rule in the Custom Rules view, select the rule and click Custom Rule Information.
Code examples for tracing
This section provides code examples which illustrate tracking tainted data from a source to a sink - and how to create a validation and encoding routine.
v “Example 1: From source to sink”
v “Example 2: Modified from source to sink” on page 161
– “Example 2: Creating a Validation/Encoding Routine from the Trace view” on page 162
– “Example 2: Creating a Validation/Encoding Routine from the Custom Rules Wizard” on page 165
v “Example 3: Different source and sink files” on page 166 v “Example 4: Validation in depth” on page 167
Example 1: From source to sink
In the following code sample, the main method calls a method,
In the following code sample, the main method calls a method,