Advanced Configuration

Accept-Language request-header value

The string sent for the Accept-Language header in all HTTP requests.

If not defined by the user, AppScan® will use the value that was sent by the browser the first time in this scan that the user opened it to record the login procedure, a multi-step operation, or to view a page.

Default: en-US

During the Explore stage AppScan might receive an unexpected response, due to the Internet Explorer header value. In such cases you should check which value should be used in the Accept-Language header when interacting with the site, and define it in this setting (or in Internet Explorer).

Custom headers

Allows you to define custom headers to add to all requests that AppScan sends the site.

Default: empty

If your site expects specific header content (for example, because access to the site is via a specific client or browser plug-in), define the header(s) here. Each header must be preceded by a delimiter. Between the header and the value must be a colon and a single space.

Format: delimiter|header|colon-and-single-space|value

;Header: Value

,Header1: Value1,Header2: Value2

Force an HTTP request without parameters to every form action

In some cases, server-side logic may behave differently when a form submission without parameters is received.

When set to True, AppScan will send an additional request, without parameters, to every form. This may result in the return of custom error pages with links to additional web pages and functionality.

Default: True

If you notice, when viewing traffic during the scan, that form submissions without parameters cause timeouts or crash the application, you may decide to set this option to False.

GSC SSL port

This setting defines the port number used in GSC for SSL communication.

Default: 443

In the case of links supplied through GSC Explore, AppScan identifies HTTPS based on this port number. If your application uses a different port for SSL communication, define it here. If the correct SSL port is not defined, AppScan will send all tests as HTTP.

Include AppScan debug headers in all requests

When set to True, an HTTP header is added to all requests sent by AppScan to the site. The header name is "X-AppScan-Debug", and its value includes information about AppScan's reason for sending this particular request (Explore, Test, Login Playback, Server Down Check, and so on).

Default: False

Configuring the scan to send "X-AppScan-Debug" headers can be useful in tracking AppScan traffic in external tools such as web debuggers, proxies, analyzers and sniffers.

Note: Some sites may reject any requests that include special headers such as this.

Maximum response length

AppScan truncates long responses to avoid memory consumption issues. This setting defines the maximum allowed response length in Megabytes. Longer responses are treated as errors.

Default: 8

If AppScan seems to miss links or get out of session, and the application is known to send long responses, increasing the maximum response length may solve the problem.

Remove 'Accept-Encoding' header

AppScan does not support all encodings, and removes the encodings it does not support. If this setting is enabled AppScan will remove the entire header and not just the encodings it does not support.

Default: True

If the server rejects AppScan's requests, returns unexpected responses, or AppScan is unable to maintain session, you should check the traffic log and compare the requests AppScan sends with those of your usual browser. If the Accept-Encoding header is different or missing in your browser, you should enable this setting.

Reuse server connections

By default, AppScan closes TCP connections after use, since open connections, and saved data, may affect scan results.

When set to True, AppScan leaves connections open after use, and attempts to reuse open connections whenever possible.

Default: False

If there are network resource exhaustion errors on the web server, changing this setting to True may solve the problem.

Security package order

AppScan supports Basic, Digest, NTML, Negotiate, and Kerberos HTTP authentication. If you want to force AppScan to use or not use a specific method, or apply an order of preference for method selection when the site/proxy allows more than one, you can edit this value.

For example, if you want to allow only NTLM and Basic, and prefer to use NTLM if available, edit this string to: ntlm, basic

Default: basic, digest, ntlm, negotiate, kerberos

If your site uses a specific authentication method and AppScan is denied access, defining the required method as the only method can solve the problem.

If you want to test your site with specific methods - say Basic and NTLM - you could configure one scan with Basic only, and another with NTLM only.

Slash Normaliz-ation

Normalize URLs by replacing two or more consecutive slashes with a single slash.

Default: True

If your site URLs utilize consecutive slashes, deactivate this setting.

Treat error response as valid

AppScan treats error pages differently to regular pages (for example, by not parsing for links). This setting lets you tell AppScan to treat error pages as regular pages for the starting URL only, or always.

When set to 0, AppScan treats all error responses as invalid.

When set to 1, AppScan treats all error responses to the starting URL (4xx and 5xx) as valid

When set to 2, AppScan treats all error responses as valid for both regular pages and the starting URL.

Default: 0

If your starting URL response is an error page, change the setting to 1.

If you want the scan to extract data from error pages, and test them, change this setting to 2.

Note that changing the default setting is likely to affect performance.

Flash:

Coverage

Defines the "coverage level" for the scan. 1 = faster scan; 2 = more complete coverage

Default: 1

For more complete (but slower) coverage of Flash content, this setting can be changed to 2.

Exclude Instances

Define problematic GUI instances to be excluded from Flash scan. Use this option only when instructed to by Support.

If scan fails or is endless due to repetitive operations. Instances should be comma separated.

File download string

In order to be able to scan Flash movies efficiently it is important that AppScan can identify controls that result in the downloading of a file. Define these here.

Note that AppScan will pause after clicking a control containing the strings defined here, for the "Long Operation wait time", even if these strings are not included in the "Long operation string" setting.

Default: Download

If the movie includes file downloads, they should be defined here.

If there are more than one, separate them with semicolons.

Example: Download;Save;Copy

File upload path

Path to a file that AppScan can upload to the application when the movie includes an option to upload a file.

Default: empty

If the Flash move includes an option to upload a file, define the path to the file, including filename, and make sure the file exists there. Note that you must also define the "File upload string".

File upload string

In order to be able to scan Flash movies efficiently it is important that AppScan can identify controls that allow the user to upload files. Define these here.

Note that AppScan will pause after clicking a control containing the strings defined here, for the "Long Operation wait time", even if these strings are not included in the "Long operation string" setting.

Default: Upload;Browse

If the movie allows the user to upload files, the text of the links or controls that do this should be defined here.

If there are more than one, separate them with semicolons.

Example: Upload;Browse;Add

Note that the "File upload path" must also be defined.

Flash movie dependency exists

Determines that the site has a Flash movie that contains another Flash movie on which the first movie depends.

Default: False

If the site contains a Flash movie that loads another Flash movie, and the first depends on the second, set this to True.

Frame rate factor

When playing Flash, increase the frame-rate by this factor (1,2,3,4).

Default: 4

By default AppScan speeds up the frame rate by a factor of four when playing movies during scans. If this is too fast to imitate real use, you can decrease this.

Load movie wait time

The length of time (ms) that AppScan waits for a movie to load before starting to explore it.

Default: 1600

If AppScan starts to explore a movie before the movie has loaded, the results will not be accurate. Therefore, if you movie takes longer than the default time to load you should increase this setting.

Long operation string

After most operations the Flash browser waits the amount of time defined in "Regular wait time" before proceeding, to allow the movie to reach its new state. In the case of operations that are likely to take longer, and that could therefore result in the scan continuing before the new state has been reached, you should define "Long operations" (such as uploading files or logging in) for which the browser will pause for a longer time.

Default: empty

Operations you might want to define as "Long operations" could be "Upload" or "Login" links.

Note that in the case of a file upload, the link you need to define here is the one that actually results in the uploading of the file, not the link that lets the user select a file for uploading.

If you enter two or more strings, separate them with single spaces.

Long operation wait time

Time (ms) for the Flash browser to wait for operations defined in "Long operation string" to complete and reach the new state.

Default: 5000

If a "Long operation" has been defined, you should define its "wait time" here.

Time between samples

Minimum time (ms) to wait between "user operations" (such as mouse clicks), to allow the movie to reach its new state.

Default: 160

If the movie has a lot of animation, the wait required between user-clicks or filling forms may be longer than the default setting. You can increase the amount here.

General:

Merge redundant tests

When set to True, AppScan sends only a single set of tests on two (or more) requests that are identical except for additional cookies. If set to False, all such requests will be tested separately.

Default: True

Changing this setting to False can impair performance; do so only if advised to by Support.

Proxy file extension filter

A regular expression that defines file extensions which will be removed from the list of URLs that is saved when you record a login, Manual Explore or Multi-Step operation. If you remove an extension from the regexp., URLs ending with that extension will not be filtered out of recordings.

Default: "\.(zip|Z|tar|t?gz|sit|cab|pdf|

ps|doc|ppt|xls|rtf|dot|mp(p|t|d|e|a|3|

4|ga)|m4p|mdb|csv|pp(s|a)|xl(w|a)|

dbf|slk|prn|dif|avi|mpe?g|mov(ie)?|

qt|moov|rmi?|as(f|x)|m1v|wm(v|f|

a)|wav|ra|au|aiff|midi?|m3u|gif|

jpe?g|bmp|png|tif?f|ico|pcx|css|

xml)$"

In rare cases where you need a particular kind of file, such as a CAPTCHA image file, included in your Login recording for reference, you could remove its file extension (in this case jp?g) from the regular expression.

Sanitize logs

Removes sensitive information from logs.

Default: False

If you need to remove sensitive information from logs, activate this option and define the pattern to be removed in the "Sensitive information pattern" option.

Note that changing this setting does not affect logs already generated.

Sanitize reports

Removes sensitive information from reports.

Default: False

If you need to remove sensitive information from reports, activate this option and define the pattern to be removed in the "Sensitive information pattern" option.

Note that changing this setting does not affect reports already generated.

Send all tests through GSC

AppScan can use GSC to send tests on some or all links that were found by GSC.

0 = Send only SOAP messages using GSC

1 = Use GSC to send all tests on links found by GSC

2 = Do not send any tests using GSC

Default: 0

If you didn't define any special security settings when exploring your site in GSC, letting AppScan (rather than GSC) send tests during the Test stage will significantly reduce scan time. However, if during the Test stage many tests get no response, or unexpected error responses, the problem may be due to the difference between how GSC and AppScan send requests. Sending such tests using GSC may solve the problem.

Sensitive Information pattern

A regular expression that defines one or more groups that will be filtered out of logs and reports, if the Sanitize Logs or Sanitize Reports options are activated.

Default: empty

If you need to remove sensitive information from reports or logs, activate the relevant option ("Sanitize logs" or "Sanitize reports"), and define one or more groups in a regular expression here.

The sensitive text is replaced with: **CONFIDENTIAL 1**, **CONFIDENTIAL 2**, and so on.

JavaScript™:

Automatic JavaScript Execution in Manual Explore

You can configure AppScan to extract all JavaScript-generated links on pages that were manually explored, even those that were not triggered during the Manual Explore.

Default: False

This can be a way of increasing coverage when manually exploring.

Clear cache

If set to True, JavaScript execution (if enabled), will not cache requests sent during login. This may increase scan time and file size.

Default: False

Fetch external links

When JavaScript Execution is enabled, allow AppScan to fetch external links even if their server is not configured in AppScan as an additional server.

Default: False

HTML pages frequently link to external JavaScript source files, such as Dojo and jQuery source files. If you want JavaScript Execution to access all relevant links discovered during the Explore stage, without adding all the servers to the list of Additional Servers and Domains that AppScan tests, activate this setting.

Note that AppScan will fetch the link, but will not test it, or parse it for new links.

JavaScript and Flash filter

This regular expression defines pages that on which JavaScript will not be executed and Flash not parsed, during the Explore stage of the scan. (It does not limit JavaScript parsing.)

Default: empty

If AppScan repeatedly crashes or freezes on a specific page containing JavaScript or Flash (this can be confirmed by reference to the Traffic Log), defining the page here will solve the problem.

JavaScript link pattern

AppScan uses a variety of patterns to identify links in JavaScript code. If your site uses unusual patterns they should be defined in this regular expression.

Default: empty

If AppScan seems to miss links from your JavaScript code, and your site uses unusual JavaScript link patterns, define one or more patterns here to tell AppScan what to search for.

Localization:

HTML encoding

Overrides the encoding defined in your site's HTML responses.

Default: empty

If the content of responses in the scan results looks distorted, this may mean that:

1) The encoding method was not correctly identified by AppScan, or

2) The encoding method is incorrectly defined in your site's HTML

To solve 1: Select the correct method in the Explore Options drop-down list.

To solve 2: Enter the correct encoding method here.

Parameters & Cookies:

Exclude redundant JSON parameters from testing

JSON content type body can contain multiple values of a single parameter that need not be tested individually. When set to True, AppScan attempts to identify redundant values and limit testing to a subset, reducing scan time.

Default: True

If you find that a particular, significant parameter was not tested, change the setting to False.

Exclude redundant XML parameters from testing

XML content type body can contain multiple values of a single parameter that need not be tested individually. When set to True, AppScan attempts to identify redundant values and limit testing to a subset, reducing scan time.

Default: True

If you find that a particular, significant parameter was not tested, change the setting to False.

Track custom parameters in headers

This setting applies only to scans saved with ADAC v. 8.7.0.1 or earlier. In later versions the default behavior changed to True, and the setting is controlled for individual parameters and cookies in: Configuration > Parameters and Cookies > Parameter Definition > Tracking Options > Match: Header and Body (default) or Body only (see Parameter definition).

By default AppScan (8.7.0.1 and earlier) searches for custom parameters only in the body of responses, not in their headers. If you change this setting to True, AppScan will search in headers too.

Default: False

If AppScan gets out of session due to changes to a parameter in the response header, changing this setting may solve the problem. Note that this may increase scan time.

Track dynamic parameters in Test stage only when inline content exists

Tracking dynamic parameters during the Test stage may result in performance problems. Therefore, by default, dynamic parameters are tracked during the Test stage only in responses with inline content.

Default: True

Change this setting to False only if this kind of tracking is essential.

Server Down Detection:

Check for "server down" in Explore

Enables the sending of heartbeat requests to check for "Server Down" during Explore stage.

Default: True

If AppScan gets server-down errors during the Explore stage, and the server is not down, this may be due to the server blocking the frequent heartbeat requests.

If AppScan frequently gets out-of-session during scanning, this may be due to the Starting URL being sent to the server as a heartbeat, without cookies.

Deactivating this setting may solve the problem, but note that AppScan will not be able to verify server status.

Check for "server down" in Test

Enables the sending of heartbeat requests to check for "Server Down" during Test stage.

Default: True

If AppScan gets server-down errors during the Test stage, and the server is not down, this may be due to the server blocking the frequent heartbeat requests.

If AppScan frequently gets out-of-session during scanning, this may be due to the Starting URL being sent to the server as a heartbeat, without cookies.

Deactivating this setting may solve the problem, but note that AppScan will not be able to verify server status.

Explore stage reconnect attempts

When AppScan is about to finish the Explore stage but several tests failed due to "server down", and the server is still down, AppScan will try to connect to the server several times.

Default: 5

If you know that your server is sensitive, or you see that the scan stopped due to a communication error while several tests failed due to communication errors, you should increase this number.

Request retry interval

Interval in seconds before resending failed requests (including failed heartbeat requests).

Default: 1

If you know that you have a poor connection or an unstable server (which would result in false negative results, or reduced coverage), you can increase this interval to reduce the impact.

Request retry limit

Number of times to retry sending failed requests.

Default: 2

Increasing this setting may result in a more efficient scan if your server is unstable or communication is poor.

Server down timeout

When AppScan is unable to connect to the server or gets out-of-session, this setting defines (in seconds) for how long AppScan will try to reconnect or get back into session before stopping the scan.

Default: 185

If you have a slow connection, or your server takes a long time to reload after down time, you might want to increase this setting.

Server-down heartbeat interval

Interval in seconds between "server down" heartbeats.

Default: 3 s

Max: 60 s

If AppScan gets server-down errors during the scan, it may be due to a poor connection or unstable server. Increasing this interval may solve the problem.

Test stage reconnect attempts

When AppScan is about to finish the Test stage but several tests failed due to "server down", and the server is still down, AppScan will try to connect to the server several times.

Default: 5

If you know that your server is sensitive, or you see that the scan stopped due to a communication error while several tests failed due to communication errors, you should increase this number.

Session Management:

Ad domains

Regular expression describing common web advert domains. Requests sent to these domains when the login sequence is recorded, will be discarded.

Default: ad\d.googlesyndication| doubleclick\.net|coremetrics\.|webtrends\ .|112\.2o7\.net|view.atdmt.com| ad.yieldmanager.com|ads.adbrite.com| oasn04.247realmedia.com| segment-pixel.invitemedia.com"

Since the login sequence is replayed continually during the scan, you can improve scan efficiency by filtering out these unnecessary requests.

Note that if you delete the regexp altogether, no domains will be filtered out.

Clear cookies before playing login

Determines whether cookies are deleted before replaying the login sequence.

Default: True

Common static parameter values

Common static parameter values. Used for the detection of non-random parameter values, which should not be tracked during login.

Default: |true|false|\bon\b|\boff\b|\ bout\b|checked|enabled|log\s?in|log\ s?out|exit|submit|sign|ever|disabled| agree

Disable Explore stage in-session buffering

During the Explore stage: If the response to a request indicates that the user was out-of-session when it was sent, AppScan queues the request to send again. This insures that as much of the site as possible is scanned.

Default: False

If your site throws the user out of session frequently, in-session buffering may result in the Explore stage continuing indefinitely. Setting this option to True will make the Explore stage faster, but may reduce site coverage.

In-session before multi-step operations

By default AppScan verifies in-session status before replaying multi-step operations.

Default: True

If you want to test multi-step operations with a non-authenticated user, or if your multi-step sequence includes login steps, change this setting to False.

In-session heartbeat interval

Interval in seconds between in-session heartbeats.

Default: 5

If AppScan gets out-of-session during the scan, it may be due to a poor connection or an unstable server. Increasing this interval may solve the problem.

Login content type filter

Regular expression defining content types that should be filtered out of the login and multi-step operation sequences. When a login or multi-step operation sequence is recorded, requests whose responses include headers with these content types will be removed from the sequence. Therefore, when AppScan replays the sequence during scanning, requests whose responses contain headers with these content types will not be sent as part of the sequence.

Default: text/javascript|application/javascript|

application/x-javascript|image|text/css

If your site's login procedure, or one of the multi-step operations you have recorded, requires clicking on a link that contains a header with a content type listed here, you should remove it from the regular expression.

Login retry interval

Interval in seconds before re-sending failed login requests.

Default: 3

If AppScan gets out of session, and repeated login retry attempts fail, this may be because the server is sensitive to frequent login attempts. Increasing this interval may solve the problem.

Multipart Content Type Filter

To reduce unnecessary memory consumption, certain content types are automatically filtered out of multipart requests (requests that contain more than one content type). Only content types defined in this regular expression are included in multipart requests; all others are filtered out.

content_without_content_type_header

Default: text/|text/plain|application/javascript|

application/json|application/rtf|application/xml|

text/xml|content_without_content_type_header

If an important content type is filtered out of requests, add it to this regular expression. You may also be able to reduce memory consumption by removing unnecessary content types so they will not be sent.

Navigational parameter hosts

Regular expression describing hosts. Used for the detection of navigational parameters (by value), which should not be tracked during the login sequence.

Default: https?://

If your site uses unusual hosts in navigational parameters, that are not filtered out by the default regexp, you can add them to improve scan efficiency.

If you delete the item navigational parameters might not be identified properly.

Navigational parameter scripts

Regular expression describing server-side scripts used in the detection of navigational parameters (by parameter value) which should not be tracked during the login sequence.

Default: /[^/\.]+\.(htm|jsp|jsf|ws|dll|asp|php|do)

If your site uses unusual server-side scripts in navigational parameters, that are not filtered out by the default regexp, you can add them to improve scan efficiency.

If you delete the item navigational parameters might not be identified properly.

Navigational parameters

Regular expression describing navigational parameters, which should not be tracked during the login sequence.

Default: \bnav|url|page|step|redirect|request|

location|target|argument|item|article|

goto|node|action|ctrl|control|source|

menu|frame|command

If your site uses unusual navigational parameters that are not filtered out by the default regexp, you can add them to improve scan efficiency.

Modifying this regular expression might result in insufficient scan coverage or improper session tracking.

Parse in-session page

If set to False AppScan will not parse the in-session page, and will not update tracked parameters or cookies whose values were changed in the in-session page.

Default: True

If your in-session page does not contain tracked cookies or parameters, you can improve performance by changing this setting to False. Note, that if set to False, AppScan will not update cookie/parameter values on the in-session page, which could result in getting out-of-session.

Password parameter name

Used by Recorded Login Analysis to identify the password parameter. Its full name is needed.

Default: password|pass|pswd|pwd

Sometimes, when you import a login (rather than record it using Action-Based Login) AppScan may fail to identify the password parameter name. If this happens the Password field in Scan Configuration > Automatic Form Fill will be empty. If this happens, add the full password parameter name here.

Requests between heartbeats

Following an in-session detection request, AppScan will send at least the number of requests defined here before sending another in-session detection request.

Default: 1

In cases where a slow response from the server results in the scan consisting mostly of in-session detection requests (see Traffic Log), increasing this value can reduce scan time.

Special Patterns:

Exclude from Automatic Form Fill

Parameter names listed here are excluded from the Automatic Form Filler.

Default: ^CFID __EVENTVALIDATION __VIEWSTATE ^CFTOKEN __EVENTARGUMENT __EVENTTARGET ^BV_ 

Parameters with very long values may slow down the scan and increase file size. If your application uses parameters with long values, and they are not needed for filling forms, add them to this list.

Tests:

CSRF: Pattern of meaningful request

By default AppScan tests POST requests, and requests whose response was "Transaction Successful", for Cross-Site Request Forgery.

This setting lets you define additional requests as "meaningful" for Cross-Site Request Forgery vulnerability, in addition to POST requests.

This definition is used in conjunction with "CSRF: Pattern of meaningful response".

Default: ^POST

If you want to test for Cross-Site Request Forgery on GET requests too, change this regular expression.

CSRF: Pattern of meaningful response

By default AppScan tests POST requests, and requests whose response was "Transaction Successful", for Cross-Site Request Forgery.

This setting lets you define additional responses as "meaningful" for Cross-Site Request Forgery vulnerability, in addition to "Transaction Successful".

This definition is used in conjunction with "CSRF: Pattern of meaningful request".

Default: Transaction Successful

If you want to test for Cross-Site Request Forgery on requests that receive other kinds of responses, define them in this regular expression.

Disable cookie testing

This setting is used to turn off cookie testing altogether.

Default: False

If cookie testing for your application results in a very long scan, you might want to disable it. However, doing so might result in security issues being missed ("false negatives").

Disable cookie testing for static content

Don't test cookies in requests for pages with this extension.

Default: ;htm;html;ahtm;ahtml;

chtm;chtml;fhtm;fhtml;mht;

mhtm;mhtml;css;css1;js;

In order to reduce scan time and memory consumption, you may want to exclude additional types of page extension. If so, add them to the list of extensions to exclude, separated by a semicolon.

Don't test directory or page

This option lets you define a regular expression to exclude specific directories or pages from attacks during the Test stage. Note that this will only exclude the directories or pages defined, and not any subdirectories or files.

Default: /wps/[^/]*/!ut/

If you know that certain directories or pages are not vulnerable, or are concerned that testing them might harm site stability, you can exclude them from the scan by defining them in this regular expression.

For excluding a folder and all its sub-folders, see Exclude Paths and Files

Extract links from all responses

By default during the test stage AppScan will only search for new links in vulnerable responses.

Default: False

If you think AppScan might miss links, or that its coverage isn't sufficient, you can enable this setting, though doing so will increase scan time and file size.

Follow all automatic links

By default AppScan only follows automatic links* that are likely to contain vulnerabilities. These are: iFrame, Frame and Redirect. You can configure it to follow all types of automatic link.

Note that requests that match the regular expression defined in "Automatic links to ignore" will never be sent, regardless of this setting.

Default: False

If you think your site may contain a vulnerability in other types of automatic link, such as scripts, enable this setting. This will increase scan time and file size.

Login after test

Send tests in a single thread, and verify in-session, or send login sequence, after every test.

0 = False

1 = Send tests in a single thread, and verify in-session after every test. If out-of-session, send login sequence.

2 = Send tests in a single thread, and sent login sequence after every test.

Default: 0

Settings 1 or 2 may be needed for applications with a sensitive session, or that require frequent logouts to avoid session or memory issues. They significantly increase scan time.

Multi-step Operation: Validation limit

The maximum number of consecutive requests from a Multi-Step Operation sequence that will be validated in Cross-Site Scripting tests.

Default: 0

Pattern to ignore in response

This regular expression defines sections of the response that AppScan will ignore when analyzing test responses.

When comparing responses to decide if a test succeeded, AppScan measures the percentage of change in the entire response. If the response is very long, and the change very small, AppScan might ignore the difference and miss the vulnerability.

Default: <input[^>]+(__VIEWSTATE|__

EVENTTARGET|

__EVENTARGUMENT|

__EVENTVALIDATION)

[^>]+>

If your site sends responses that include long sections that are not important, defining them here can improve scan accuracy and performance.

Refresh original response interval

Interval in seconds before refreshing the original response (by sending the request again) during the Test stage.

One of the ways AppScan decides whether a Test response reveals a vulnerability is by comparing it with the Explore response. When an Explore response is older than the value set here, the Explore request will be sent again, before sending tests, so that an updated Explore response can be used for the comparison. This is important for cases where the Explore response is likely to vary with time, and comparing the Test response to the outdated Explore response might result in a false positive.

Default: 30 (seconds)

If you are sure that your application's responses will never become outdated in this way, you can change this setting to zero to reduce scan time. Explore stage requests will then never be resent.

Send port listener tests

By default AppScan doesn't send port listener tests because of the likelihood of failure and the time it takes to validate.

Default: False

If the external site is part of your network, so that it is aware of local IP addresses, you might want to activate this type of blind SQL injection test.

Similarity threshold

Certain tests compare the response they receive with the original response, to decide whether the response is similar, and therefore whether they succeeded. For most tests the similarity threshold is 95%. In some test policies it is higher.

If you enter a value between 1 and 100 (percent), it will override the thresholds for individual tests.

Default: 0 (Use AppScan thresholds)

If your site has no "dynamic" text that causes the similar responses to be slightly different, increasing this percentage may reduce false positive results.

XSS: Test all reflected probes

Usually multiple occurrences of the payload text in a response from the site have the same level of vulnerability, therefore AppScan tests only one of them.

Default: False

Set this to True if you want to test all occurrences of the payload text in a single response.