Blind Persistent Cross-Site Scripting Audit Start


I'm scanning a .Net Web application and, at end of audit (verified XSS), WebInspect start a "Blind Persistent Cross-Site Scripting" and then stop (Status: Interrupted).

Wenn I Resume the scan after a few minutes, I get the same result.

I'm using WI Version 10.30507.10 and WI Agent is installed on the target aplication.

PS: Under Logs/Diagnsotis, I've a dump file with a "please_send_with_dump.Asc" file. 

Thanks for your help. Pierre

  • Pierre:

    To help me some as I look for guidance for you, can you tell me if this .net site is a Web Form or POST Data site that you are scanning or just a regular site.  This would help in the discussion some and offering some thoughts for consideration.

    With both Blind XSS and Blind SQL Inject it does have some affect based on the data the site is leveraging.  As always, I would recommend considering the HP Software Education courses for WebInspect as we do cover these and can offer more direct input.

    Joel E. Natt CISSP, CRISC
    Hewlett-Packard Enterprise Software Education
    Exam Development Lead – Hewlett-Packard Enterprise Security
    Get Training:
    Get Certified:

  • Pierre;

    The most basic step at this point would be to open a Fortify Support case (, and ship them that DMP file plus the accompanying text file.  They should be able to decipher what occurred to cause the halt/crash using that data.  Additional options of sending them your system details can be found under the WebInspect Help menu > Support Tool.

    If you wished to trouble-shoot this yourself, here is a formula that would help that investigation.  Sometimes there is an adjustment to a check or new check that has a faulty logic or action.  Once the "bad check" has been identified, our Research Group can correct this very quickly and push the updated check out to all users via SmartUpdate.

    Repeat the scan using these options.  Your goal is to repeat the crash, but capture adequate data to identify what/when it occurs.  The default scan settings run ~15 threads, so it is often one of several dozen "final" probes that was the one that actually caused the outage, not the last one noticed.

    • Change the Requestor Threads to Single Shared Requestor (absolute slowest scan!, single-tracking the threads).
    • Enable the Traffic Monitor feature, which will save 100% of the traffic in the scan.
    • Consider starting the scan deep-linked to the area of interest and use Restrict To Folder and/or Session Exclusions to focus only on the area where you feel the trouble lies.  (See the Single Shared Requestor setting above to understand why.)
    • Try to synchronize your machine's clock with the time on the target server.  Not required, but helps in reading the logs.
    • After the scan:
      • Review the final probes for any issues, using the Site Tree pane and the Traffic Monitor pane.  The X-Memo headers in the HTTP Request generally tell you what caused the request to b made and possibly the individual check ID#.
      • Contact Fortify Support.
      • Export the scan to a *.SCAN file, and include the option for "Include Logs".  Send that to Support for help in reviewing the crash.
      • Since the WebInspect Agent is present, export its logs to FPR format (see its User Guide) and send along with the SCAN file.
  • Hi Joel

    this .net site is a classic Web Form application.

    Considering the HP Softare Education, I'm allways interresting by the e-Learning. You told me (11.11.2014) that you plann to update it from 9.3 to new version 10.30. Do you know when it will be ready?

    Regards, Pierre

  • Hi Hans.

    thanks a lot for your explanations.

    For now I can't re-scan this application but your advices will be usefull for a futher scan.

    Regards, Pierre