Performing a Scan

Performing a scan is easy. You simply click "New Scan" to start the Scan Wizard dialog box (shown in Figure 1).

You can perform a number of scan types. The first checks a single Web site using an URL you provide as a starting point. The drop-down list box includes three test Web sites you can use to check your installation and to learn more about the software.

The second option checks a single Web site based on the output of a Web crawler. Instead of crawling the Web site again, Web Vulnerability Scanner uses the list you provide. You can use this approach to exclude pages you don't want to check or to check pages from multiple Web sites.

The third option lets you scan a list of Web sites based on individual entries in a file. All you do is create a file that contains a list of URLs to check.

Finally, the fourth option lets you locate and scan Web sites on a network based on a range of IP addresses. This is, perhaps, the most powerful feature of Web Vulnerability Scanner; you can use it to locate all Web sites on a network, even those you don't know about.

Figure 1: Select the kind of scan to perform.

I tested all of the options, but decided to show the single Web site option in this section since you're likely to start with it, may not need the others. Once you enter the URL, you click Next and see the Target Select dialog box shown in Figure 2. Web Vulnerability Scanner provided all of the information that you see. I tested a number of Web sites, and it wasn't ever wrong. On the off chance that it is wrong, you can modify the information here to ensure you obtain a good scan of the Web site.

Figure 2: Check the target information for the Web site you want to scan.

Once you select a target, you choose the Scan Options (shown in Figure 3). The scan profile determines which tests the product runs. Web Vulnerability Scanner comes with many built-in tests, and the default option performs them all. However, you might want to perform a custom test. You can create new tests to check for other kinds of vulnerabilities.

Figure 3: Define the tests you want to run and determine how you want the application to crawl the Web site.

The lower half of this dialog box contains crawling options. Figure 3 shows the default setup, which works fine in most cases. The only problem I ran into was the "Submit Forms" option, which tends to fill the Web site database with unusable data. You might want to clear this option when testing a production Web site.

The next page of the Scan Wizard asks for the site's security information. You only need to provide this information when the Web site requires it. It's helpful to run the scan multiple times when working with secure Web sites, so that you can see the effects of the scan when using different user accounts. A scan that works well with an average user's account might reveal security problems when working with an administrator account.

After you fill out the required information, you see a summary dialog box. Click Finish and the product will begin the scan. At this point, you might want to get that cup of coffee you've been wanting, or read the latest trade press articles (or just hang around DevSource to see what's new). A scan can consume quite a bit of time, depending on what you test.

Interpreting the Results

The scan results appear in two windows, as shown in Figure 4. To display this information, you select Web Scanner in Tools Explorer (the left window). The center window contains a list of the problems that Web Vulnerability Scanner found, with two areas of the hierarchy. Shown in the figure is the list of errors for the Web site as a whole, such as using an older version of PHP. Following the list of alerts is the site structure, where you can find information about individual Web pages.

Figure 4: You can begin finding Web site problems after you perform a scan.

The right window contains detailed information about each error that Web Vulnerability Scanner found. Figure 5 shows a more complete view of this information. The details tell you a lot about a particular error. For example, you can discover the basis for the error information, the error severity (so you can create a list showing the order in which to fix the error), a description of the error, and references you can use to learn more about the error. These references are a nice touch, because researching an error often takes longer than finding and fixing it!

Figure 5: The detailed error information helps you understand the problem and provides references to fix it.

You may want to keep the cracker view in mind as you perform your testing. In one case, I tested a Web application and it passed with flying colors locally. Placing the application onto a hosted server didn't provide the same results. Suddenly, the application had all kinds of errors. because someone hadn't configured the hosted Web site correctly and the server had older software installed. Consequently, you can't test locally and simply assume your Web application is ready for prime time. After you test it locally, you must also test it in the production environment.

You may encounter some false positives with this product as well. For example, one of the rules tells the product to look for a Robots.txt file. Normally, this check works fine. However, on a secure IIS system that I checked, the product returned an "access denied" message, rather than an "object not found" error. Testing with a browser showed that the page wasn't found (because it didn't exist on that server). Consequently, you may find that the occasional test doesn't work as expected in some environments.

Fortunately, you can verify some of the individual Web page checks by viewing the helpful information that Web Vulnerability Scanner provides. Individual Web page details include general information, any referrers, the headers (both request and response), any inputs to the page, the page itself (right click the page and choose View Source to see the actual code), HTML structural analysis, and any alerts associated with the Web page.