WebInspect using legacy version of Mozilla

Hello,

We are facing issues while running WI scan for few of applications as these applications are not supporting Mozilla 59 version which is used by WebInspect to generate login macro in both basic scan and guided scan mode.However as a alternate solution we are using webproxy macro for these apps.

Any idea how to upgrade mozilla versions of WebInspect or when we can expect this fix?

  

  • You mentioned Guided Scan. The latest version of the macro recorder is not compatible with Guided Scan. It is only available in Basic Scan after modifying the version in Application Settings. There should be a Fortify Unplugged video coming out Monday demonstrating this.

    If you are actually using the latest version and still experiencing a problem the next step would be to modify the user-agent string in the macro recorder.
  • Thanks for your reply.
    Latest version of Macro recorder - How can I check which version do I have. I am using WI 19.1.0
    For latest version of macro recorder what exactly I need to modify to work with Basic scan?
    You mentioned about modifying the user-agent.does it mean in xml based macro file or changing browser options from WebInspect user agent options?
  • Verified Answer

     here is the Fortify Unplugged video I was referring to

    About modifying the user-agent string in the new Macro Recorder 5.0, there is no longer a need to modify xml files and add a JavaScript step. When you start the recorder, you will notice a new look. Click on the gear to enter settings.

    MacroRecorder-New.png

     

    When the TruClient General Settings dialog box opens, you will see an entry for User Agent. Simply enter your modified user-agent string there.

    useragent_settings.png

     

  • Hi
    We have recently upgraded Webinspect to 19.20 and enabled macro engine 5.0
    How ever we are facing issue while recording macro with macro 5.0
    It is not opening the macro recorder how ever some random URLs are getting populated in the browser.
    I hv attached the sample screenshots,logs for your reference. Did you face this type of issues?

    Regards
    Amrityam
    macro 5.0 issues screenshots.zip
  • I have not see this being reported yet. What version of WebInspect are you using? or are you using the Macro Recorder from the Fortify Marketplace?

    Do you have any AV software installed on the machine? These seem to cause problems with the default profile we use and some of the scripts therein to redirect to the defined URL in the scan settings.

  • Hi  ,

    We are using webinspect standalone 19.20 version.

    CASE-1

    ----------

    Fortify WebInspect 19.20 is installed on windows server 2016.Here Symantec Endpoint Protection is installed.

    CASE-2

    ------------

    I tried installing WebInspect Macro Recorder 5 from fortify market place in my local machine from below link : https://marketplace.microfocus.com/fortify/content/webinspect-macro-recorder-5

    In my local Avecto Endpoint is installed.

     

    In both the cases the result is same and it is opening some random urls in the browser.

     

    Thanks

    Amrityam Rout

  • My apologies as I just noticed your attachments to the original post.

    1. Are you a local administrator of the machine?
    2. Are you running through a proxy?
    3. Do you have your profiles in the default location or are they symlink'd?
    4. These appear to be random locations, but they are not. When the Macro Recorder is started, we create a "fresh" FireFox profile in your %temp% folder. They start with the following ASCMasterProfile. This is what you are seeing. 
    5. The default URL (<install_folder>/dat59/WebTruClientBrowser/extensions/TruClientBrowser@hpe.com/aboutblank.html) That URL contains a javascript file that is supposed to redirect you to the URL defined earlier in the Scan Settings Wizard.

    With all that being said, when I've seen this type of behavior it is due to AV/AM installed on the machine that is either not allowing the script to execute properly or during installation did not allow all of the files to be extracted.

    In your installation folder (C:\Program Files\Fortify\Fortify WebInspect\) you will see two files: browser59.zip and dat59.zip. Close WebInspect or any open Macro Recorder windows. Copy these two files to your desktop and extract them. After extraction, copy the extracted contents back to the install folder overwriting any files/folders when prompted.

    We also recommend that any AV/AM be disabled during installation and scanning with WebInspect.

    See if this resolves the issue. Here is a short video clip showing how it should work: WebInspect: https://www.screencast.com/t/8ICmUDyyY3uU 

    Macro Recorder 5.0 from the Fortify Marketplace should simply open to:

    MR50_MP.png

  • Hi ,

    Thanks for your response.

    Please see my response below

    1)Are you a local administrator of the machine? - Yes

    2)Are you running through a proxy? - No

    3)Do you have your profiles in the default location or are they symlink'd? - I am not sure on this and don't know how to check..

    But the ASCMasterProfile folder you mentioned in path:  C:\Users\A-AMRI~1\AppData\Local\Temp\12

    And the WebInspect logs and scan data path located at:  C:\Users\a-Amrityam Rout\AppData\Local\HP\HP WebInspect

    I have tried your solution by extracting browser59.zip and dat59.zip file and then replacing those in  path : C:\Program Files\Fortify\Fortify WebInspect . Still no luck.

    The Anti Virus Symantec Endpoint Protection installed as per is Organization policy and I am not sure if we can be disable it or not.

    I am attaching the files from ASCMasterProfile path.Please take a look if required.

    We stuck scanning our application which are using Okta SSO, with macro 4.0 those are giving Nightly stopped working issue and in macro 5.0 we getting the above issue.

    I am just wondering is this issue coming due to any space in user profile.like in my case the user profile is "a-amrityam rout", the the login macro is trying to open "rout.com" from my surname.

    Thanks and any help would be much appreciated.Current we have reached out to the microfocus support and they are not able to identify the problem now.

    Amrityam Rout

    ASCMasterProfile files.zip
  • I was able to find your ticket and reviewed the history therein...well some of it anyway  

    With that information and based on what you provided attached here, I have some additional observations.

    1. I am not sure if you captured those temporary files after closing the Macro Recorder. If you captured the files after closing then some of them could have been erased/removed. Take a look at the folder with the Macro Recorder open.

      If not, then you are missing a number of files in your profile. This could be the reason for the behavior you are seeing. This is usually indicative of AV/AM blocking the transfer of these files. If you are unable to disable SEP completely we would at least ask that you look into adding some exclusions.

      comparison.png

      What happens is we copy the profile to the temporary location and the run some scripts. This doesn't appear to be happening in your environment.

      If after viewing that folder when the recorder is open and you do have the files/folders, then simply type your URL in the address bar, click record and carry-on to see if you can record.

    2. I see in one of your screenshots where you are unable to access the site where you get a timeout error. Do you have any issues with access this in a normal browser?

    3. Your initial question is about MFA with Okta or Duo. With Duo there is a workaround'ish; however, it is clunky. Generally we say the best way to handle this is to either test the site in a dev environment or obtain an account to bypass MFA requirements.

      Look at it this way, if we were able to "fool" Duo then that defeats the purpose of MFA and those providers would not be happy. If we can do it then hackers would be able to as well.

      Even if you choose the option in Duo to remember for 14-days, that will not work as each time we call the login macro is a new browser session. The "workaround" we provided to a customer yesterday was:
      1. Configure WI for single-thread mode.
      2. When authenticating with Duo choose the option to call.
      3. Be ready to answer a number of phone calls and press a button on your dialpad.

        For this customer it worked and he was happy. I cautioned him on this method as Duo calls are not free and you only get a certain amount based on your plan. Again, that is a choice they took and proceeded with the scan.