WebInspect Tips: Changing settings to improve scans

Although running WebInspect with ‘out of the box’ scans settings might be the easiest way to start a scan, it is almost sure to produce unexpected results. Configuring any web application scanner is tricky, but by following these simple steps to fine tune the scan 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 mis-configured 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 theses 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 is able to 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 others 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.

Comments
varun.asok | ‎11-06-2009 09:37 AM

Hi,

i'm getting an error while using this web inspect. its an intranet site ssl based. the error which i'm getting is "The request was canceled by Web Proxy". Wat is the proxy should i set. ?

| ‎11-09-2009 01:22 AM

Man Farsi ra sohbet khardoom :smileywink:

Always wise to ommitt the Form/Field that changes an Account's password from the FormValues File. Using the default FormValues is always a risky thing to do, I never do it on Production. And keep in mind the 'Default' value will be used for any field that isn't specified within the file!

todd.densmore | ‎11-09-2009 09:33 PM

@Varun

Can you give me more details about your problem? Does your IT department require a connection through a proxy? Step 4 of the Scan Wizard allows the configuration of a web proxy, which might be needed in your case. If you need more general WebInspect support, please feel free to call our support hotline:

1. Call 1-800-633-3600.

2. Select option #2 for Software.

3. Enter your SAID (Service Agreement ID) followed by #.

4. Select option #1 for Enterprise Application Software.

5. Select option #5 for Application Security Center

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.