UPDATE! The community will be go into read-only on April 19, 8am Pacific in preparation for migration on April 21. Read more.
UPDATE! The community will be go into read-only on April 19, 8am Pacific in preparation for migration on April 21.Read more.
Absent Member.
Absent Member.
8682 views

If login macro is not working tomorrow

Jump to solution

I have started a scan for an application and I have used a login macro for it.  A day after the scan when I checked, Login macro was not working and scan has paused/stoppeed. I confirmed that credential for the application has been changed. 

I want to resume the scan where I had left. What I need to do?

 

Your help is highly appreciated. Thanks 

0 Likes
1 Solution

Accepted Solutions
Micro Focus Expert
Micro Focus Expert

Simply put, you would need to reset the credentials back to match the Login Macro, then press Resume.  I am assuming that WebInspect changed to user's password to something such as "foo" (see the Web Form Ediotr input file) as it was Crawling the site.

However, this will not give you what you want.

Once the credentials were changed, WebInspect continued to send many Requests for sessions it had in its Crawl queue, and they will not be re-requested if you only press Resume.  As far as WebInspect is concerned, the HTTP Responses it received earlier for those non-authenticated Requests were valid and those sessions have been decremented from its queue.  If there would have been findings in the Responses to those Requests, WebInspect will probably not see them because it received a non-authenticated Response rather than an authenticated one.

 

What you really need to do is start a Rescan that includes an Exclusion for the page where the credentials were allowed to be changed.  Use the following process to rescan with credentials.

  • Identify the page or URL where the password can be changed.
  • Have the credentials reset to match what is in the Login Macro, or reset the Login Macro to match the new credentials.
  • Open the offending scan > press the Rescan > Scan Again buttons in the Toolbar area.
  • This will start the scan wizard with the same, original scan settings.
  • Open the setting to edit them.  This would be the Advanced (setting) button at the top of the Guided Scan Wizard, or it would be the "Settings" button on the lower-left corner of the Basic Scan Wizard.
  • Open the Session Exclusions scan settings panel.
  • Add a Session Exclusion to both Exclude and Reject the URL matching that password changing page.  e.g.  URL matches /something/Changepassword.do
  • If you had to edit your Login Macro rather than the test account, go to the Authentication scan settings panel and re-select that macro file, even if the same file name is currently specified there.  This reloads the updated macro to the Current Scan Settings..
  • Click OK to save the Current Scan Settings.
  • Proceed through the rest of the Scan Wizard and kick off your repeat scan.

 

The obvious problem now if that if there are vulnerabilities on the page where the credentials can be changed, they would not show up in this scan.  To correct for this, you might record a short Workflow of just that page and run a second Audit-Only scan against that.  The two scans can ultimately be combined in a single Report.


-- Habeas Data
Micro Focus Fortify Customers-Only Forums – https://community.softwaregrp.com/t5/Fortify/ct-p/fortify

View solution in original post

1 Reply
Micro Focus Expert
Micro Focus Expert

Simply put, you would need to reset the credentials back to match the Login Macro, then press Resume.  I am assuming that WebInspect changed to user's password to something such as "foo" (see the Web Form Ediotr input file) as it was Crawling the site.

However, this will not give you what you want.

Once the credentials were changed, WebInspect continued to send many Requests for sessions it had in its Crawl queue, and they will not be re-requested if you only press Resume.  As far as WebInspect is concerned, the HTTP Responses it received earlier for those non-authenticated Requests were valid and those sessions have been decremented from its queue.  If there would have been findings in the Responses to those Requests, WebInspect will probably not see them because it received a non-authenticated Response rather than an authenticated one.

 

What you really need to do is start a Rescan that includes an Exclusion for the page where the credentials were allowed to be changed.  Use the following process to rescan with credentials.

  • Identify the page or URL where the password can be changed.
  • Have the credentials reset to match what is in the Login Macro, or reset the Login Macro to match the new credentials.
  • Open the offending scan > press the Rescan > Scan Again buttons in the Toolbar area.
  • This will start the scan wizard with the same, original scan settings.
  • Open the setting to edit them.  This would be the Advanced (setting) button at the top of the Guided Scan Wizard, or it would be the "Settings" button on the lower-left corner of the Basic Scan Wizard.
  • Open the Session Exclusions scan settings panel.
  • Add a Session Exclusion to both Exclude and Reject the URL matching that password changing page.  e.g.  URL matches /something/Changepassword.do
  • If you had to edit your Login Macro rather than the test account, go to the Authentication scan settings panel and re-select that macro file, even if the same file name is currently specified there.  This reloads the updated macro to the Current Scan Settings..
  • Click OK to save the Current Scan Settings.
  • Proceed through the rest of the Scan Wizard and kick off your repeat scan.

 

The obvious problem now if that if there are vulnerabilities on the page where the credentials can be changed, they would not show up in this scan.  To correct for this, you might record a short Workflow of just that page and run a second Audit-Only scan against that.  The two scans can ultimately be combined in a single Report.


-- Habeas Data
Micro Focus Fortify Customers-Only Forums – https://community.softwaregrp.com/t5/Fortify/ct-p/fortify

View solution in original post

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.