Properties view: selected project
In this mode of the Properties view, you configure parameters for the selected project. Project attributes depend on previously created global attributes. Properties vary according to the selected project.
- Selected project Overview tab
- Filters
- Pattern Rules and Rule Sets
- File Extensions
- Sources
- JavaServer Page (JSP) Project Dependencies
- Project Dependencies
- Compilation
- Optimizations
- Precompile Tab (ASP.NET only)
Selected project Overview tab
The Overview tab displays:
- Project Name. The project can be renamed by entering a new name in the field.
- Project File name and path
- Project Type
- Configuration: This section displays the target configuration. For .NET and C++Objective-C projects, this section displays the target configuration that has been saved in the Project Dependencies tab. For all other project types, this section displays Default.
- Filter option: Select Filter findings contained in external sources to filter out any findings discovered in files that are not source files of the scanned project. This option reduces noise for projects where findings are reported in compiler-generated or temporary files, such as ASP.NET.
- Vulnerability analysis cache options: If you are refining your assessment of a code base by
scanning iteratively and adding custom rules, and then re-scanning without
changing the source code, you can dramatically reduce scan time by setting the
project properties to use a vulnerability analysis cache. To do this, select the
Enable Vulnerability Analysis cache check box in the
project properties. The first time you scan the project after selecting this
check box, a vulnerability analysis cache will be created. For every subsequent
scan of the project, the vulnerability analysis cache will be used and scan time
will be reduced.
To clear the vulnerability analysis cache, click Clear cache. The next time you scan the project, a full scan will take place and a new vulnerability analysis cache will be created. You may want to clear the cache if:
- Source code in the project has changed since the last scan.
- You have made project configuration changes, such as adding or deleting source files.
- You have changed code configuration options. For example, you may want
to clear the cache if you are scanning Java™ and the class path has changed - or if you are scanning C
or C++ and you have changed the
include
path or preprocessor definitions.
Note: You can also clear the vulnerability analysis cache by selecting the Clear cache check box when creating custom rules in the Custom Rules Wizard. - String Analysis: String analysis monitors
string manipulation in Java or Microsoft™ .NET projects.
It provides the automatic detection of sanitizer and validator routines.
With this detection, false positives and negatives can be reduced.
Select the Enable String Analysis to find validator/sanitizer
functions check box to enable string analysis. The Apply
imported rules to Global Scope check box determines if
the discovered sanitizer or validator routines should be applied to
a single project or on a global level (to all projects).Note: The application of string analysis can slow a scan. It is therefore recommended that it should only be applied after code changes and then disabled for subsequent scans. In addition, the discovered routines should be viewed as suggestions and reviewed by auditors. These routines can be viewed in the Custom Rules view.
- File Encoding: The character encoding of
files in your project must be set so that AppScan
Source can
read the files properly (and, for example, display them correctly
in the source view).Note: The default file encoding for AppScan Source projects is ISO-8859-1. The default file encoding can be changed in the General preference page.
Filters
This tab allows you to specify existing filters for the selected project, and how you want the filters applied (a filter can be applied directly - or its inverse can be applied). See Triage and analysis for information about filters - and Applying filters globally for details about applying them globally.
Pattern Rules and Rule Sets
When you select a project in the Explorer view, the Pattern Rules and Rule Sets tab in the Properties view allows you to add pattern rules and rule sets that will be applied when scanning the project. Using pattern-based scanning, you search for text patterns that you want to appear as findings. Individual rules and rule sets can be applied to both applications and projects. See Customizing with pattern-based rules to learn about pattern-based analysis and Applying pattern rules and rule sets to learn how to apply rules and rule sets in the Properties view.
File Extensions
Use this tab to configure or add valid file extensions for the project - and to exclude files from scans and specify extensions as web files.
The File Extensions section lists the extensions that have been set globally in the Project file extensions preference page for the current project type (you can choose file extensions for a different project type using the File Extension Set menu). To exclude an extension from scans of the current project, select it in the list and click Exclude Extension. This causes the extension to be listed in the Excluded Extensions section of the tab.
To add an additional extension for the project, select Add Extension in the Additional Extensions section, and then enter the file extension and indicate if files with the extension should be scanned, considered as a web file, or excluded.
Setting | Description | Usage examples |
---|---|---|
Scan or Assess | Include files with the indicated extension in full analysis. |
|
Web File | Mark files with the indicated extension for JSP compilation. This setting allows AppScan Source to separate web sources from non-web sources. | If a .yyy extension is created for Java projects and marked as a Web File, files with that extension will be arranged as web sources in the projects. When AppScan Source prepares for analysis, these files will be precompiled into classes to be analyzed. |
Exclude | Do not create source files in the project for files with the indicated extension. Files with this extension will not be scanned. | Create a .zzz extension for files that are necessary to your projects for compilation, but do not need to be included in analysis. |
Sources
Specify the sources to include in the scan.
- Working Directory: The location of the AppScan Source project file (ppf) and the base for all relative paths.
- Add Source Root and Remove Source
Root: The Sources tab displays the properties established
for the project from the Project Configuration Wizard or defined in
the imported ppf.
Remove Source Root is available only when the Source Root icon is selected. It is used to remove the source code root directory.
- Find Source Roots (Java projects only): Allow AppScan Source for Analysis to find all valid source roots automatically.
- Project files are listed under the Source Root icon. Files that are excluded from scanning have a red file icon (if an excluded file is right-clicked, its menu has Exclude disabled and Include enabled). To exclude an included file, right-click it and choose Exclude in the menu. To include an excluded file, right-click it and choose Include in the menu.
JavaServer Page (JSP) Project Dependencies
The JSP Project Dependencies tab displays the properties established for the specified JSP project.
- Contains web (JSP) content: Identifies if the project is a web application that contains JavaServer Pages.
- Web context root: A WAR file or a directory that contains the WEB-INF directory. The web context root must be the root of a valid web application.
- JSP Compiler: Out-of-the-box, Tomcat 7 is the default JSP compiler setting (the default JSP compiler can be changed
in the Java and JSP preference page). To
learn about the compilers that are supported by AppScan
Source, see System requirements and installation prerequisites.
Apache Tomcat Versions 7 and 8 are included in the installation of AppScan Source. If the Tomcat 7 and Tomcat 8 preference pages are not configured, AppScan Source will compile JSP files using the supplied Tomcat JSP compiler that is currently marked as default. If you want to employ an external supported Tomcat compiler, use the Tomcat preference pages to point to your local Tomcat installation.
If you are using Oracle WebLogic Server or WebSphere® Application Server, you must configure the applicable preference page to point to your local installation of the application server so that it can be used for JSP compilation during analysis. If you have not already completed this configuration, you will be prompted by a message to do so when you select the JSP compiler. If you click Yes in the message, you will be taken to the appropriate preference page. If you click No, a warning link will display next to the JSP compiler selection (following the link will open the preference page).
Project Dependencies
The Project Dependencies tab displays project properties. Configuration settings on this tab vary by language, for example:
- Options allow you to select any additional required compiler parameters.
- JDK settings are specific to Java.
- Preprocessor definitions
are specific to C/C++ code. When specifying preprocessor definitions,
do not include the compiler's
-D
option (for example, specifya=definition1
instead of-Da=definition1
). When specifying multiple definitions, use a semicolon-delimited list. - The target configuration is available only for .NET and C++Objective-C projects.
Compilation
- Options: Additional required compiler parameters for the project configuration.
- Use JDK: Identify the JDK used for the project compilation, as
configured in Preferences. See Preferences.
Java projects may refer to a local Java Development Kit (JDK) location. When projects move to the server, the JDK path may no longer be valid. To transfer local projects to the server, you must identify the default JDK path for each project that specifies a named JDK.
Note: Out-of-the-box, the default compiler for JSP projects is Tomcat 7, which requires Java Version 1.6 or higher. If Tomcat 7 is kept as default, using an earlier JDK will result in compilation errors during scans. - Validate: Validate assures that project
dependencies are correctly configured. It checks Java projects for configuration conflicts between
sources and the class path and for compilation errors. A
conflict exists if a class in a class path is duplicated
in a source root. (If a conflict exists, modify the class path to
remove the conflicting class.)
After checking for conflicts, Validate determines if the project compiles and reports any compilation errors.
Optimizations
- Precompiled classes: Use precompiled Java or JSP class files instead of compiling during the scan. When selected, this option disables the source stage options.
- Stage sources files to minimize effects of compile errors: Controls
whether AppScan
Source copies
the sources to the staging directory.
Correct for packages not matching the directory requires Java Compile to open each source file.
Clean staging area between scans increases performance between scans.
Precompile Tab (ASP.NET only)
Precompilation is accomplished by making
an HTTP request to a special page (by default, precompile.axd
)
in the website. This page is processed by a special HTTP handler specified
in the web.config
. This handler compiles the entire
site, including client.aspx
files, to the Temporary
ASP.NET Files directory in the .NET framework directory, where they
are all then scanned.
To scan ASP.NET 1.1, you must instrument
the website such that the website compiles and builds debug information.
Subsequently, the fact that a website compiles and builds debug information
is, in and of itself, a security vulnerability. You can safely ignore
this vulnerability as the scan requires it. However, ensure that your
deployed application is not compiled with debug=true
in
the web.config.
To precompile an ASP.NET
1.1 website, add this element as a child to the <system.web>
element
in your web.config file:
<httpHandlers><add verb="*" path="precompile.axd"
type="System.Web.Handlers.BatchHandler"/></httpHandlers>
You
should also set debug=true
in the compilation element.
For example:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<httpHandlers><add verb="*" path="precompile.axd"
type="System.Web.Handlers.BatchHandler"/>
</httpHandlers>
<compilation
defaultLanguage="c#"
debug="true"
/>
...
This element specifies to the website that the page, precompile.axd will
be handled by the special .Net System.Web.Handlers.BatchHandler
class.
This class precompiles the contents of the website to the Temporary
ASP.NET Files directory.
- Website: Request target to precompile the site. The default location is precompile.axd. Precompile.axd is a virtual file and maps to the file specified in the web.config file.
- Output directory: The directory targeted by the precompilation. AppScan Source finds the precompilation output in this directory.
- Precompile the ASP.NET website: AppScan Source automatically precompiles and scans the precompiled output during a scan.
- Stop scan if precompile fails: Selecting Precompile the ASP.NET website and Stop scan if precompile fails, stops a scan if precompilation fails. Otherwise, the scan continues only on the website's primary output.
- Compile Now: Test to see that the precompilation, based on the current settings, succeeds before scanning. Compilation output displays in the Precompile Output pane.
- Additional Assemblies: For any .NET project type, specify additional assemblies to scan.
- Project References: List the directories in which to search for referenced assemblies in .NET assembly projects and existing .NET projects.