Using Web-based Application Testing Techniques

We’ve already discussed much of what you need to know in order to configure a system for Web-based application testing. The “A Case for Using Multiple Machines” section at the beginning of the chapter discusses the need to set up a two-machine network as a minimal testing setup. Failure to perform this setup means that you’ll probably end up spending more time diagnosing errors when you move the application to a production setup because users won’t have the luxury of using a single machine setup.

Unfortunately, using a multiple machine setup can create new problems for the developer. For example, the “Enabling Authentication for Debugging” section of the chapter covers some of the problems that you’ll run into with remote debugging. Of course, your debugger isn’t the only problem. When you use a LocalHost setup, everything needed to run the application is on a single machine. Using a separate server means additional cost, setup time, and problems during development. Unless the two machines are side by side (a configuration I recommend), you’ll also spend more time running between your desktop machine and the server. However, the additional problems are worth overcoming because you have a much better chance of creating a good application with all the required functionality the first time.

When you test your application, you’ll normally begin with manual testing, and then move on to automated testing as the project progresses and you can develop a test suite. In general, automated testing looks for expected responses to data input requests and application events. Unfortunately, most automated testing does little to check the security of your application. Security testing means checking for unexpected input. Crackers rely on unexpected input to cause application crashes and let them gain access to back doors. When you want to perform automated security testing, you normally have to create a custom test suite specifically for that purpose.

Note

A number of consulting agencies specialize in hacker testing of your Web site. For example, the Secure Web Online site at http://www.securewebonline.com/services.htm discusses this type of service. You can also find an interesting Aberdeen Group report on the topic of automated security testing for Web sites at http://www.aberdeen.com/2001/research/07020009.asp. (You have to register with the Web site to review the report.) Note that this is one of those reports that states developers lack time to perform security testing—you always have time to perform security testing because testing is always less expensive than cleaning up after a virus or a cracker. It’s also helpful to check out product reviews from high profile consulting companies such as PricewaterhouseCoopers. For example, you can find a review of AppShield and AppScan at http://www.pwcglobal.com/extweb/manissue.nsf/DocID/4728487E7DAD27D985256C790071619B.

When you do decide to perform security testing for your application, make sure you spend time researching the current exploits for your system using written documentation (such as security reports) and technical updates (such as the techniques found on some Web sites). In some cases, these security reports can provide you with everything needed to perform a good test. The Microsoft Knowledge Base articles usually fall into this first category. In other cases, you’ll find techniques that you should perform for every Web application. The email exchange on the SecurityFocus site at http://www.der-keiler.de/Mailing-Lists/securityfocus/secprog/2001-07/0001.html is an example of this second category. In this case, the author shows how you can use a few simple additional characters in the fields of a form to fool SQL Server into giving you complete access to the data on a Web site. The extreme ease of this technique should prompt every developer to perform the range and data type checks discussed in the “Preventing Data Entry Errors” section of Chapter 3.