Absent Member.
Absent Member.
10243 views

Workflow Macro Recorder Hangs - Can not complete the macro recorder and start the scan

Jump to solution

Hello HP WebInspect Team,

I was trying to start a scan for one of our customer application using Workflow Macro Recorder. As I have to scan a perticular module of the application I choosed Workflow Macro Recorder to record that module(its wizard based form workflow) and start the scan.

As I proceed with the macro recorder, the macro recorder stuck in between and does not proceed further with an error page from the application. From application development team I understood that, the application behaves only if we open multiple forms for the same user in different browser it will create error state for that perticular user form. After the error state has been created we can not access that perticular form in the module. 

Please advice how can I proceed with the scan in this scenario using workflow recorder or any other alternative ways to overcome this challenge. Let me know if you need any further information from my end.

Thank you.

Labels (1)
0 Likes
1 Solution

Accepted Solutions
Absent Member.
Absent Member.

Just wanted to add in summary - The application at a moment only supports single form(wizard based) for a single user in one browser. In this case how can We start scan using WebInspect both Macro recorder mode or step mode. Thanks

View solution in original post

0 Likes
2 Replies
Absent Member.
Absent Member.

Just wanted to add in summary - The application at a moment only supports single form(wizard based) for a single user in one browser. In this case how can We start scan using WebInspect both Macro recorder mode or step mode. Thanks

View solution in original post

0 Likes
Micro Focus Expert
Micro Focus Expert

Bikramkeshari;

It sounds like your site prevents revisiting a user record once it has been viewed and/or edited, is that correct?  This behavior will be challenging for a dynamic scanner, since the typical process is to Crawl the pages, and then come back to revisit the page and fuzz the available inputs found there.

If you look at the Default Scan Setting s > Method panel, you will note that the default Crawl and Audit Mode of WebInspect is Simultaneous.  This means that while some Requestor threads are Crawling the site (5 by default), there are other threads Auditing what was just Crawled (10 by default).  Your scenario may call for changing this Mode to Sequential, which will perform all of the Crawling actions first and then follow with the Audits afterwards.  Specifically, you may need to set the sub-option there to "Test each session per engine type (session driven).  This will ensure that the page gets Crawled and then immediately Audited before moving on to the next session/link/page in the queue.

From the Help guide:

  • Test each engine type per session (engine driven): WebInspect audits all sessions using the first audit engine, then audits all sessions using the second audit engine, continuing in sequence until all engine types have been deployed.
  • Test each session per engine type (session driven): WebInspect runs all audit engines against the first session, then runs all audit engines against the second session, continuing in sequence until all sessions are audited.

 

Now if the site has an issue with multiple threads (separate browsers) running simultaneously, you may need to adjust the Requestors scan settings.  You can test this by logging into the site using several separate browsers (not separate tabs).  If you are prevented from doing that with the browsers, then you may need to go to the Requestors scan settings panel and switch from Use Separate Requestors to use a Single Shared Requestor.  This will slow your scan down to having only a single thread running, which will make it the slowest possible scan.  If that is how the target behaves, then that may be your lot.  You might get lucky and be able to increase the single Shared Requestor count, which would be akin to using several browser tabs to log into the same app at once as the same user.  I say "lucky" because it depends on the target app's acceptance, nothing anything WebInspect can control.

 

Furthermore, if you cannot jump to a known page in the app, then you might need to change how WebInspect Crawls through the available links of the site.  You will find this on the General scan settings panel > Crawl Details.  The default method is to operate in Breadth First mode, chasing all links across and down the hierarchy without a true rhyme or reason.The alternate setting would be Depth First, which is where WebInspect must follow select click paths down and into the application in order to reach select sessions.  If you enable this, the scan will also be slowed, since these click paths must be replayed over and over with each deeper link.  You will probably also nee to enable the box at the bottom for Audit Details, to ensure the Audit Engines follow these same click paths during the fuzzing activity.

If there is any way to have your developrs alter this limiting behavior of the site in terms of revisiting a user page, that will make you job of scan configuration much simpler.


-- 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.