FAQs

Active View is a consolidated view of your web apps and vulnerabilities drawn from previous scans. Web apps can be drilled into for more detailed information regarding the vulnerabilities that have been found. Vulnerabilities similarly can be reviewed to see affected web apps.

These are the top-five worst web apps that are known to have medium, high, and / or critical vulnerabilities.

See more: At-Risk Applications

These are the top-five worst medium, high, and critical vulnerabilities that are known to exist in your environment.

See more: Vulnerabilities You Should Fix

When viewing Vulnerabilities in Active View or the results of a scan, you can select individual vulnerabilities you want to hide.

Select More options > Hide above the table to open the Hide Vulnerability dialog where you can provide a reason for hiding the vulnerability.

Selecting OK hides the vulnerability immediately. You can reveal hidden items by way of the tools menu on the table header bar.

This is done in the same way as hiding vulnerabilities with one exception: Before selecting OK in the Hide Vulnerability dialog, select True, and then select the False positive checkbox. Enter a note, and select OK.

The WAS Vulnerability Dictionary provides information about known vulnerabilities. The list, which is updated frequently, includes high-level information about specific vulnerabilities and, when appropriate, remediation steps. Low-level vulnerability information can be linked to this page for users requiring even greater detail.

Security GPA is the unique grading system used by WAS.

See more: Security GPA

WAS assigns your web app ratings based on the highest-level vulnerabilities discovered on the web app. Web app ratings are used to calculate your Security GPA.

See more: Security GPA

These two concepts comprise the most important aspects of a discovered vulnerability. The "class" is based on the type of threat presented and how it is discovered; "severity" describes the potential of immediate threat.

Possible classes include:

• Explicit: Conclusive evidence of this item was found.
• Potential: Indicators of a possible vulnerability were found.
• Recon: Visible network or asset information that could aid an attacker.
• Compliance: Item related to a security standard, such as the Center for Internet Security (CIS) Benchmarks.
• Malware: Known malware was discovered.

WAS provides a variety of ways to search and filter data.

See more: Find Information in WAS

See Create or Modify a WAS Configuration for more information.

Python compatible regular expressions.

See What are Regular Expression Fields? for more information.

Each scan gets assigned a status to provide information on its current state. You can view the status of any scan by selecting Scans > Scan Activity, and then selecting the desired scan. The scan's status appears under General Information.

See Scan Statuses for more information.

If your scan did not find anything, look for triggers under the Vulnerabilities tab for the specific web app results in question. They could indicate there was a problem with the configuration of the web app, RNA, or scanned target.

Create a Tuning Policy and set Scan timeout value to 5 or 10 minutes. Then, launch a scan with this tuning policy and the Crawling Audit policy. The scan should complete within or before the timeout you set, and it should be enough time for the scanner to make at least one authentication attempt. Once the scan completes, look for FVM WAS Scan Notification: Authentication Failure in the results. If you do not see this, and authentication was provided, the authentication should be successful. This is also a useful way to verify that the scanner can hit the targeted website if there have been connection issues in the past.

See To modify or create a tuning policy for more information.

The time the scan was paused should not factor into the overall scan timeout. For example, if a scan timeout is set to 12 hours and the scan is paused after running for six hours, and remains paused for 24 hours, when it is resumed there should be about six hours left before approaching the scan's timeout setting.

Performance

If the target website is running sluggish or goes down while being scanned, adjust the following settings to help improve its performance:

• Ensure only a single web app scan is scheduled to run against the target website at a time. The more concurrent web application scans against the target site, the worse its performance will likely be.

• Adjust the following tuning policies for the scan:

  • Increase the value for Request delay.

    NOTE: This setting controls the minimum time between requests made between the web app scanner and the target website. Increasing this duration will increase how long the scan takes to complete.

  • Decrease the value for Max audit processes.

    NOTE: This will increase the duration of the scan.

  • Decrease the value for Max crawler processes.

    NOTE: This will increase the duration of the scan.

  • Decrease the value for Max brute force processes.

    NOTE: This may increase the duration of the scan depending on the number of directories discovered during the scan.

Email Spam, Bogus Data, and Clicking

The scanner attempts to find all of the available inputs for data during the scan, and then attempts to discover vulnerabilities using those inputs by submitting payloads designed to elicit a vulnerable response. While none of the payloads are intended to be malicious or cause negative impact to the target site, they may inadvertently do so. This is most often caused by lack of data sanitazation by the target website or of the functionality exposed by the target website. Scans run without authentication are generally less likely to negatively impact the site in terms of bad data being submitted than an authenticated scan since most of the interesting website functionality is usually only available after authentication.

There are a few ways to help avoid issues or prevent them from occurring in the future once they've been identified.

• Only scan a version of site that is meant for testing or development. This is the best option for avoiding any potential negative impact to a production site.

• Add any pages with dangerous functionality or functionality that has caused issues in past scans to the blocklist in the web app definition in Fortra VM to prevent the scanner from auditing those pages. Examples of dangerous functionality include password change forms that do not validate the existing password, forms that lack basic data validation and then generate emails or trigger other automated actions, pages with destructive actions like deleting users and data, etc.

To reduce scan duration, adjust the tuning policies. See Work with Tuning Policies for details. Options include:

• If the Scan timeout value is set 14 days, decrease its value.

  NOTE: If the scan does not complete on its own, there will be a greater chance for discrepancies in results between scans.

• Increase Max audit processes, Max crawler processes, and Max bruting processes to 10. A scan spends most of its time auditing items since there are typically many inputs and things to fuzz. Keeping auditors at the max and reducing some of the other items can help maximize speed while reducing traffic, if needed.

• Decrease the value for Request delay. This will increase the rate at which the scanner sends requests to the target server.

• Decrease the value for Request timeout. This will reduce the amount of time the scanner waits for the target server to respond. Fortra does not recommend setting this value lower than 5 to provide the server enough time to process items, especially under load. Lower times may also affect accuracy depending on how long it takes the server to process various requests under load.

• Decrease the value for Max directory brute.

• Decrease the value for Max authentication brute.

• Decrease the value for Max depth.

• Decrease the value for Max page count.

The “Full Scan” scan policy, the default scan policy for VM scans, contains checks for potential CVCs. The “Penetration Test” scan policy does not check for potential CVCs because the focus of a penetration test is on vulnerabilities with exploits.