I am just doing a Crawl with a "Blank" audit using webinspect 10.10 and after I start the scan I noticed a few min in that my user accounts were gettting deleted. This is a test site, so its not a huge deal, but the problem is that my crawl will not completed because all of my login accounts get deleted before the scan can finish.
I know the command that the scan is hitting to delete the accounts but how do I create an exception to keep webinspect from hitting that command?
This issue was caused by the Crawler and not any Audits or attacks thrown by WebInspect. Essentially, the Crawler's job is to exercise everything on the site in numerous ways and numerous submissions in order to expose the most attack surface area. When doing this, it is not "smart' and will press those big red buttons that you yourself would not press, such as "Set Back to Factory Defaults", "Change Password", "Submit Case to Support", et al. ;-) Your situation shows exactly why it is important to test your scan configurations against a Test copy of your site before heading to the Production site. This gives you time to identify and configure the scan settings for minimal disruption. The alternative is to slowly and iteratively scan the site with small escalations in settings while monitoring its every move, as well as with deep understanding of what actions the site offers the browsing user.
One common way to avoid account management functions such as account deletion or password edits is to scan with a non-administrative logon, which is our recommendation. See the article within the WebInspect Help Guide (F1) regarding "Preparing your system for audit".
Another common technique is to define a Session Exclusion to avoid the trouble spot. In WebInspect 10.10, you can find this under the Edit menu > Default Scan Settings > Session Exclusions panel (7th). Previously our Session Exclusions were built mostly around identifying the specific page or URI, and you can see the product's defaults for avoiding some simple session state pages such as "signout" and "logoff". A few releases back, we expanded the selections to include items such as select Parameters, Extensions, Status Codes, and Responses.
Depending on how the submission is made, you could opt to use a filter. These can be defined under the Scan Settings > Filters panel. For example, if the deletion occurs when variable=7, you could Add a Request Filter that intercepts and changes "variable=7" to "variable=777", or any other nonsense value that will trigger nothing on the server other than perhaps a small error. This trick is particularly useful if you still need to audit the "variable" and Crawl its other valid values.
-- Habeas Data Micro Focus Fortify Customers-Only Forums – https://community.saas.hpe.com/t5/Fortify/ct-p/fortify