Web Vulnerability Scanner in Your Build Policy
Web vulnerability scanners seem to be a favorite tool for malicious users, so why is including one when you deploy a Web server so important? The scanner can address the security procedures of your Web server build policy, in particular, the following:
- Testing input validation and removing unnecessary directories
- Removing unnecessary files and verifying the permissions on the files that remain
- Ensuring strong, secure passwords
Test Input Validation and Remove Unnecessary Directories
Removing all unnecessary directories should be step one of the Web server's build policy. A scanner can assist with this procedure and, to some degree, test a Web application's resistance to input validation attacks. The IIS Unicode exploit is a good example of why this validation is important. A pre-emptive measure against this attack is to map the Web document root to a different drive than the system volume (e.g., D:\InetPub vs. C:\Winnt\System32), which blocks command-line access via vulnerable directories such as /scripts/. Unfortunately, the /msadc/ is commonly mapped to C:\Program Files\Common Files\system\MSADC\, which is on the same drive as the system root. So if the sole security measure is re-mapping the Web document root then the server still will be vulnerable because a (very likely) unused directory remains enabled. A good vulnerability scanner will search for the IIS Unicode exploit against default and common directories—of which there can be more than 20.
Remove Unnecessary Files and Verify Permissions
The second step of a Web server's build policy should be to remove unnecessary files and verify the permissions on the files that remain. The majority of checks that a vulnerability scanner conducts relate to sample files, default files, and incorrect file permissions. The default install of a Lotus Domino server, for example, places a slew of databases (.nsf files) within the Web document root. Several of these files, especially the names.nsf file, contain sensitive information about the server that any anonymous Internet user may be able to read. You cannot blindly rely on Apache's security either.
An improper install of the WWWBoard message board application leaves the password file readable to anyone who cares to look for it. Older versions of the Big Brother system-monitoring tool expose arbitrary files outside of the Web document root or they allow command execution. Even improper permissions for .htaccess files give up user passwords.
Ensure Strong Passwords
The hardest part of a build policy to implement (for anything other than HTTP Basic Authentication) is strong password creation. A good scanner will be able to perform rudimentary password guessing to ensure that no passwords can be easily deciphered. For example, form-based authentication such as mail.yahoo.com or www.hotmail.com is more difficult—but not impossible—to attack.
Introduction 
Web Vulnerability Scanner in Your Build Policy 
The Scanner Review 
