How to scan with WebInspect an application that uses Adobe Flash Player?

I am trying to scan an application using WebInspect Enterprise.  This is one that requires a logon macro because of our SSO system.  But when I try to record a logon macro using the WIE console tool, after login using the built-in Firefox rendering engine (browser) the app simply displays a message that it requires Adobe Flash Player version 10.3 or greater to be installed.   But this cannot be installed into the tool's rendering browser.  I tried using IE and it logs on correctly, but upon replay it never displays the logon page.  I have the same problem using the guided scan feature. 

Is there a way to make Adobe Flash Player available in the default 'browser'?


  • Verified Answer

    There is no way to install plug-ins or applets to the browser used within WebInspect and its associated recording tools, however, there is a way to do what you want.  :-)   Anytime a plug-in or browser client is required for browsing a target site, the WebInspect answer is generally to use the Manual Step-Mode scan type found within the Basic Scan Wizard.  This scan type simply has WebInspect open a hidden Web Proxy instance on a dynamic port, and it them spins up the user's installed browser pre-configured to that listener port.  After the manual data capture, the user switches back to WebInspect, clicks the Finish (Step-Mode) button and then the Audit button, and that sets the attack engines loose on the manually recorded sessions.  If you need it to listen on a Static port rather than a dynamic one, you must first adjust the Application Settings > Step-Mode panel in WebInspect.

    So, for your scenario, you can use your own installed browser (with the necessary Adobe features) and Web Proxy to produce the Login Macro, with final editing performed within the Login Macro Recorder.  Below I will explain how.  You may only need to use this for generating the Login Macro, and not actually need the Manual Step-Mode scan type for the actual test.

    Recording a Login Macro with the included Web Proxy tool

    1. Ensure you have the plug-ins the browser requires.

    2. Launch Web Proxy, check its settings for its listener port ( plus any network proxy it must daisy-chain through.

    3. Start the Proxy's listener, and it should show the port details in its lower left-hand corner.

    4. Set your browser's proxy settings to use Web Proxy.

    5. Record the Login process that is needed.  (Do not log out!)

    6. Stop the Proxy listener.

    7. Remove any extraneous sessions that were recorded.

    8. Click on the File menu > Create Macro.

    9. For a Login Macro, enable the box indicating "Login".

              (For a Workflow/Start macro, simply provide the file name and you are done.)

    10. For a Login Macro, you must enter a Logout Condition before you may save it.  Enter some place-holder text such as "[STATUSCODE]666".

              (There is a mild issue here in that the Condition field does not accept a "real" signature, so use just a dummy entry.)

    11.  The file name defaults to "sessions.webmacro", so change that to something more useful.

              (Note that both Login Macros and Workflow/Start Macros share the same file extension, but they cannot be used interchangeably.  Get in the habit of specifying "Workflow" or "Login" in the file name!)

    12.  Close the Web Proxy once the Macro is saved.

    13. Double-click your new Login Macro file, and the Login Macro Recorder should open.  Or you can open it from the Login Macro Recorder.

              (The recorder window should default to the IE Rendering Engine, since the Web Proxy recording is session-based and not event-based like the Firefox/Truclient recorder.)

    14.  DO NOT Play the macro just yet.

    15. Open and correct the Logout Conditions settings.

             (Erase your placeholder, dummy signature.  Add one or more proper signatures/triggers.)

    16. Save the Login Macro.

    17. Try out the Replay option and adjust the Macro if needed.

    18. Save the Macro again and exit.

              (In a pinch, you might not save it a second time, but try it out in a live scan and see if it operates fine despite Playback issues.)

    Where do I get Logout Conditions?

    Normally, the Login Macro Recorder reviews the recorded sessions on playback and formulates the necessary Logout Condition automatically for the user.  You can augment this or, in the case of Web Proxy recording, you may need to build it yourself ("manually").  Logout Conditions are simply signatures used to indicate to WebInspect when session state is being lost or dropped and it then replays the Login Macro.  Obviously, these signatures need to be unique to the logout and/or time-out process so the Macro does not get replayed excessively during your scan.  The Help Guide in WebInspect has an article on Regular Expression Extensions which will educate you on the simplified formats WebInspect offers for the signature(s).

    To manually identify proper Logout Conditions, you would use the following process.

    1. Run your browser through Web Proxy, or any intercept proxy tool.

    2. Log into the site, wait a little bit, or browse around some, and then trigger the logout button.

    3. Identify the HTTP Response that occurred right at that point and write a signature that matches on it.

    4. Try logging in again and then wait an excessively long time before refreshing a page, to see if you get a different, timed-out message instead.

    The most common signature tends to be of the form, "[STATUSCODE]302 AND [HEADERS]theloginpage.aspx".  You might also add secondary/additional signatures to account for multiple scenarios of session state loss, e.g. "[BODY]your\ssession\shas\stimed\sout".  See that Help article to understand this more fully.  I have run across some sites that could identify injection attacks and they would then log the user off with a different, third message that was needed as a third Logout Condition.

    All of your Logout Conditions will be processed as Boolean OR, so any single Logout Condition matched will trigger the Login Macro to replay.  Be aware that your signature must match on plain text seen in the raw HTTP Response, not on some visible text seen within the browser.  This is because the visible text might actually be an image file, or what is rendered in the browser is actually the 2nd or 3rd Request/Response made after the initial Redirect order is followed.

  • Hi Hans,

    Thanks for your detailed reply. I met the same problem as John so tried to use the steps you listed to record login macro. I meet problem that Web Proxy cannot capture the sessions from the Web Site with Flex technology. It can capture other session from the same browser but different web site such as and so on. Could you please let me know if you have any solution? Thanks. 

    I also met the problem that Web Proxy cannot capture the sessions from the Applet web UI. Do you have any information on how to capture? Thanks.

    Have a good day.

  • Ellen;

    The traffic for the browser client/plug-in was assumed to be HTTP protocol.  If it is not using HTTP/S, then Web Proxy will not be able to capture it.  If it is indeed HTTP traffic, then you will need to closely review the client application's proxy configuration.

  • The traffic is in fact https and 'Web Proxy' is capturing it correctly.  However, 'Web Proxy' does not appear to be capable of spoofing the SSL certificates in a way that a browser will allow access.  For example, Fiddler will spoof the SSL certs so that if your browser 'trusts' the Fiddler 'CA', it will trust the spoofed SSL server certs.  Short of turning off SSL on the application being scanned, do you see any way around this?  Is there another way to record a dialog that can be imported into 'Web Proxy' and converted to a macro?  (such as maybe using the browsers' own 'developer tools' record features?)

  • WebInspect also has this capability via the "WebInspect Root Certificate" which you should find in the machine's Trusted Root CA certificates store.  That certificate will be presented by the web proxy tool to your browser and because it's "trusted" the end result should be what you'd expect.  What's the symptom that you're encountering which leads you to believe that this trust relationship is not working correctly?

  • I went to look at the installed root CAs and certificates, and sure enough, the 'WebInspect' ones were all there, like you said.  (I was not expecting that WebProxy was this sophisticated).  In any case, I enabled the proxy again and this time, everything worked perfectly, where last time all I saw were certificate errors and warnings about spoofed sites and untrusted certificates.  Perhaps it was fixed due to a recent reboot - who knows.  But it works!

    Thanks much!