Although running Fortify WebInspect with ‘out of the box’ scan settings might be the easiest way to start a scan, it is almost sure to produce unexpected or even undesirable results. Configuring any web application scanner can be tricky but following these simple steps to fine tune the scan can ensure more accurate results will be generated. 

Know your website 

Performing a manual assessment of your website (before using any tools) will help you quickly spot misconfigured scans, tweak scan configuration parameters, and ensure more consistent results.

The first step is to become familiar with the site topology - directory structure, the number of pages, submission forms, etc. Perform a manual site survey and take notes. If you have access to the source, look at the file structure. If not, hover over the menu links and notice the site structure of the URLs. Are URL parameters used to drive the site navigation? If so, record them and use them to drive WebInspect. 

It is also important to have some understanding of how the site operates behind the scenes. Different websites tend to handle common administrative tasks in unique and unexpected ways. For example, some websites require users to re-enter their passwords and a pass a ‘captcha’ test before assigning a new password. Other sites allow a password to be changed simply by entering a new password. 

Knowing the basics of the site mechanics will go a long way toward heading off mis-configured scans and getting familiar with the layout of your site is the best way to help WebInspect cover the entire site. 

Protect your data 

Web application security tools try to force websites to accept input data that they may not have been designed to handle. Therefore, one side effect of auditing a website for vulnerabilities is that ‘garbage data’ can be injected into the database. On a database-driven site (like most blogs or CMS systems), this junk data will show up in other unexpected and very visible ways. After a scan, you may find that your default website language has been changed to Farsi, test files have been uploaded, the new blog color theme has been set to ‘Early 80s Disco’, or 13 new users have been added – complete with nonsense test Posts. 

To minimize these risks, scan a non-production version of the target website if possible. Sometimes audits are necessary on a complicated production server setup.  If this is the case, make a backup of the entire production database and verify the ability to successfully restore it before a scan.  

Limit the scan 

If the local server hosts multiple web applications, it is important to restrict the audit to the application of interest. For example, my local Apache installation hosts 12 web applications in the htdocs root folder. When I want to scan “WordPress”, I often forget to restrict the audit, and end up with a noticeably longer scan time, and an unusually large numbers of vulnerabilities. A quick glance at the “site” tree in WebInspect will quickly show whether the scan has started crawling into folders that were not intended. 

To prevent the scan from ‘running away’ (taking too long to complete), open the scan settings before the scan is launched, check the “Restrict to folder” option and select “Directory and subdirectories”. Take note: this option is not enabled by default, so this may be worth remembering. Also, make sure the start URL either contains a start page, or the initial directory ends with a trailing “slash”. 

Login Macros 

Login Macros are essential to correctly scanning a website yet may unknowingly be the root of many failed scans. Before creating a new login macro to allow WebInspect to successfully gain entry to the actual site, choose a user with limited ability to modify the site. If one is not available, create a new user with the lowest role possible. For example, WordPress allows 4 roles with varying degrees of ‘power’: Administrator, Editor, Author and Contributor. Scanning WordPress as the Administrator user may result in any of several undesirable scenarios, including the destruction of the entire blog, while scanning as a ‘Contributor’ should only result in a few extra unpublished blog entries. 

Check your login macros for errors during the scan. Often a login macro that is incorrectly recorded may fail to login to the site which causes the scan to produce invalid results. Symptoms include abnormally short scan times, lack of vulnerabilities, or large numbers of errors in the error log. 

Other times the macro may not be able to log back into the website during a scan – even after the first login has been successful. For example, login macros tied to a user account that can change its own password will prevent the macro from logging back into the site. Once this happens, the error log may fill up with errors and the scan may stop. It is important to monitor the scan periodically and assess the scan ‘health’. 

Conclusion 

Some users might be unaware of the unintended consequences of web application vulnerability scanning, while other users might need help understanding their scan process. Although these simple steps are not remedies to solve issues scanning complex sites, they will help rudimentary scans to produce more valuable results. The more information that is provided to WebInspect through the scan configuration settings, the better the outcome of the scan will be.

Originally posted by Todd Densmore on October 28, 2009 - /cyberres/b/sws-22/posts/webinspect-tips-changing-settings-to-improve-scans