Preparing Your System for Audit

Glossary Item Box
WebInspect is an aggressive Web application analyzer that rigorously inspects your entire Web site for real and potential security vulnerabilities. This procedure is intrusive to varying degrees. Depending on which WebInspect policy you apply and the options you select, it can affect server and application throughput and efficiency. When using the most aggressive policies, you should perform this analysis in a controlled environment while monitoring your servers.

Effects to Consider
During an audit of any type, WebInspect submits a large number of requests, many of which have "invalid" parameters. On slower systems, the volume of HTTP requests may degrade or deny access to the system by other users. Additionally, if you are using an intrusion detection system, it will identify numerous illegal access attempts.

To conduct a thorough assessment, WebInspect attempts to identify every page, form, file, and folder that composes your application. If you select the option to submit forms during a crawl of your site, WebInspect will complete and submit all forms it encounters. Although this enables WebInspect to navigate seamlessly through your application, it may also produce the following consequences:

If, when a user normally submits a form, the application creates and sends e-mails or bulletin board postings (to a product support or sales group, for example), WebInspect will also generate these messages as part of its probe.

If normal form submission causes records to be added to a database, then forms submitted by WebInspect will create spurious records.

During the audit phase of an assessment, WebInspect resubmits forms numerous times, manipulating every possible parameter to reveal problems in the applications. This will greatly increase the number of messages and database records created.

Helpful Hints
For systems that write records to a back-end server (database, LDAP, etc.) based on forms submitted by clients, some WebInspect users, before auditing their production system, create a backup copy of their database and then reinstall it after the audit is complete. If this is not feasible, you can query your servers after the audit, searching for and deleting records that contain one or more of the default form values used by WebInspect. You can determine these values by opening the Web Form Editor.

If your system generates e-mail messages in response to user-submitted forms, consider disabling your mail server. Alternatively, you could redirect all e-mails to a queue and then, following the audit, manually review and delete those e-mails that were generated in response to forms submitted by WebInspect.

WebInspect can be configured to send up to 75 concurrent HTTP requests before waiting for an HTTP response to the first request. The default thread count setting is 3 for a crawl and 5 for an audit (if using separate requestors). In some environments, you may need to specify a lower number to avoid application or server failure. See Scan Settings: Requestor for more information.

If for any reason you do not want WebInspect to crawl and attack certain directories, you must specify those directories using the Excluded URLs feature of WebInspect settings (see Scan Settings: Session Exclusions). You can also exclude specific file types and MIME types.

Finally, WebInspect tests for certain vulnerabilities by attempting to upload files to your server. If your server allows this, WebInspect will record this susceptibility in its scan report and attempt to delete the file. Sometimes, however, the server will not allow a file to be deleted. For this reason, part of your post-scan maintenance should include searching for and deleting files whose name begins with CreatedByHP.