The Cracker Eye View of Web Site Security with Web Vulnerability Scanner - ' Testing Scenarios ' (
Page 2 of 4 )
Testing Scenarios
Because of the way Web Vulnerability Scanner performs its task, I used a number of test scenarios. The first scenario is a simple Web site that consists only of standard HTML. How boring, you might think, but it's important to see how this product works with something where the approach is decidedly low tech. Doing so establishes a baseline of sorts, and shows whether the product detects errors on a Web site with specific flaws in a controlled environment. I didn't see anything unexpected with this test. I had scanned and tested it with other products in the past and knew which vulnerabilities to expect; Web Vulnerability Scanner found all the errors.
I also tested Web Vulnerability Scanner using all the vendor-supplied Web sites. These include a test site for PHP, ASP, and ASP.NET. The software includes the URLs for these test sites, which you can select from a drop down list box. They all worked as anticipated; more importantly, using these tests helped me learn more about Web Vulnerability Scanner and helped me ensure I had set it up correctly.
The next test scenario is an enterprise-level Web site, which I used in my last book, Web Development with Microsoft Visual Studio 2005 (Sybex, 2006), to test every aspect of ASP.NET. The various pages include a shopping cart application, security login pages for employees, database access, and a wealth of other ASP.NET features. In this case, Web Vulnerability Scanner located a couple of problems that I hadn't found. It turns out that the "ASP.NET scripting in secret problem" I mentioned earlier bit me.
Visual Studio 2005 provides a built-in Web server.
Learn how to using the Visual Studio Built-in Web Server from the Command Line. Click here to read more.
I wanted to see how Web Vulnerability Scanner would react to this Web server, since it runs in a different kind of an environment from public Web sites. The software seems to work fine with the built-in Web server, which means that anyone can build and completely test their Web application, inside and out, before deploying it. Using a combination of a code scanner (such as SecureObjects) and a Web page scanner (such as Web Vulnerability Scanner) should ensure that your deployed application has few, if any, security problems related to the application itself. Of course, these tests only check the application; you still need to secure your Web server.
My final test involved a mixed code Web site. I created a test site using Visual MainWin (see my review) that mixes Java and .NET code. This is one type of application where Web Vulnerability Scanner really shines, because it can locate problems that a code scanner can't. For example, it can detect problems caused by marshalling data from Java to .NET (or vice versa). Mixed environment coding is becoming a significant reality for larger corporations, so knowing whether the mixed environment exposes you to unique security problems is important.
Finally, to test the scanning feature of this product, I loaded up Web servers on two computers over a network with some Web applications. This tests a scenario where Human Relations decides to add a Web server to the network without telling anyone. Web Vulnerability Scanner worked fine. It located all the Web applications on the two systems. In fact, it located some that weren't on standard ports, so the port feature works, too.