Absent Member.
Absent Member.

The test application is getting down when I run the webinspect scan. What may be the reasons?

The test application is getting down when I run the  webinspect scan. What may be the reasons?

Labels (1)
1 Reply
Micro Focus Expert
Micro Focus Expert

This can occur with weak or sub-standard test boxes, but the causes can vary.  It is always possible that a recently updated WebInspect check is the cause, and once investigated our research team can adjust it accordingly and update everyone via SmartUpdate.  Below are ways for you to determine the cause.  I will assume that you are using WebInspect 10.40, released/upgraded in April 2015.

  • Which scan Policy are you using?  The Standard Policy is a good balance point and Best Practice.  The Hazardous policies such as Assault or All Checks are likely to include some Denial of Services or Buffer Overflow checks that are a bit too unstable to be included in other Policies and those might cause a disruption.  The WebInspect DoS and BO checks normally do not leverage the full exploit, just a shortened version of it and look for timeout delays from the target server.

  • Are you using the default thread counts on the Requestors scan settings panel, i.e. 5 of Crawl and 10 of Audit?  Increasing these can overload a slow web server or network link, and likewise lowering them can help prevent such an issue but will lengthen the scan duration.

Here is how to recreate the crash with data captures.  Configure a scan with the following scan settings changed from your prior configuration.

  • Enable Traffic Monitor - increases size of logs.
  • Switch the Requestors settings to "Single Shared Requestor" - makes for the longest, slowest scan possible, but it single-tracks the requests in an orderly fashion.
  • Lower the Requestors settings for "Stop Scan If Loss Of Connectivity" to something like 10 instead of the default 75 - causes WebInspect to halt sooner when the target goes off-line.
  • Coordinate the clocks on the WebInspect machine and the target server.
  • Consider enabling a process/file/activity monitor on the target web server, e.g. Carbon Black for Windows, Performance Monitor with recording, et al.
  • Run the scan and watch the target server.  WebInspect should halt soon after the target crashes.
  • In WebInspect's Site Tree, change to the Sequence view.  This shows the HTTP Responses in the order they came from the web server.  Somewhere towards the end will be the offending HTTP Request, but it may not necessarily be the last one shown.
  • Similarly, open the Traffic Monitor pane and review the ending section of that listing.
  • Review any logs you may have on the web server.
  • Collect a scan export (*.SCAN) with the Logs included (option), plus the logs or messages from the target web server and submit these to Fortify Support (support.fortify.com) for review assistance.

-- Habeas Data
Micro Focus Fortify Customers-Only Forums – https://community.softwaregrp.com/t5/Fortify/ct-p/fortify
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.