Password Protect Your IIS 5.0 Web Pages

You've probably been faced with the need to password-protect a Web page, browsable directory, or Web-based application on your IIS server, especially if you administer a company intranet site that contains sensitive management reports or a database update page that requires controlled access. When I was first presented with this requirement on my intranet site, I spent days researching many of the available methods and code examples on the Internet. Nearly all the examples were written in Java or JavaScript and used a password file or database to store the correct password.

Many of these examples lacked basic security, and some even embedded the correct password in the source code. Any savvy user could then simply display the source code to determine the password and gain entrance. Even in the case of a separate JavaScript dialog box popping up, users could display the code from any example by right-clicking the protected page URL and performing a Save Target As operation. Users could then save the file to their hard disk, where they could edit the page and display the source code.

You can password-protect your IIS 5.0 and IIS 4.0 Web pages in two ways—programmatically or using built-in IIS security. (For more information about IIS authentication, see "Related Reading.") I show you two programmatic methods—one that uses JavaScript (or JScript, Microsoft's implementation of JavaScript) and one that uses an Active Server Pages (ASP) application. I then show you the possible uses and inherent security flaws with each type of scripting method. Finally, I describe how to use the inherent security features in Windows 2000 and IIS 5.0 to set up password protection easily and quickly.

Using JavaScript to Secure Web Pages
The JavaScript examples I found during my research validate a password that's stored in a separate password file. Setting the file protection correctly is important for preventing users from directly viewing the password file's contents. In some examples, the file was set for Anonymous read access so that the executing JavaScript code could open and read the password file when a browser invoked the script. After users examined the source code, they could type the password file's URL into the browser and download or display the password file's contents. A few examples call a JavaScript function to take advantage of password encryption, but users can still view the source code and the algorithm used. In defense of this method, most casual users wouldn't take the time to crack the password, even if they knew the algorithm. Because the validation code is checking for a match between the entered password and a calculated checksum, the script never displays the real password. These scripts have a separate function that prompts the page developer for the desired password, which in turn generates a checksum number. This number is then embedded into the page's header section as a password variable.

Another interesting approach is a JavaScript file that doesn't need to place a password in the source or use a password file. In such an example, the password is the name of the protected page minus the HTML extension. Many JavaScript examples use this approach. Listing 1 shows a script example that requires only eight lines of code. However, after viewing the source code, breaking into the protected page requires only a few more seconds.

Many of these JavaScript examples are fine for an intranet site in which you just want to discourage employees from entering protected pages. However, they're not the type of protection you would use for sensitive protected pages on the Internet, where you would potentially go up against top-notch intruders. Such proficient intruders would be in and out in no time and would probably send you some code improvements just to wiggle the knife a little. Setting up JavaScript page protection is simple to implement because most code examples are short and easy to read, but a more secure way to password-protect IIS Web pages exists.

Using ASP to Secure Web Pages
Over the past few years, ASP code solutions have begun to show up for Web-page password protection. The ASP examples for page access control are a better approach for IIS administrators because these examples integrate nicely with existing data-driven ASP pages. Many ASP authentication examples use Microsoft Access or Microsoft SQL Server databases to store the user password, thereby increasing security. A few clever ASP solutions contain a dozen or so lines of code that use an HTML form that posts to itself. Using the POST method, the form verifies the password, which is embedded in server-side ASP code that users can't view.

A second version of such an application contains about 25 lines of code and uses cookies to grant access after the initial page visit. One good by-product of using session cookies is that users are required to enter a password only once. You can set the cookie to have an expiration date to prevent later cached access, and the password is stored in the server-side ASP code, not the cookie. To prevent subsequent users from accessing the protected page, consider setting the cookie to a short expiration period if shared systems are used.

Listing 2, page 13, shows protect.asp, a code example that uses 11 lines of VBScript code and a standard form that posts to itself. The password access is stored as a session variable called SecureAccess. As long as the user's current session stays active, SecureAccess will equal Yes, and the user can access the page without reentering the password. The script checks for a hidden field value in the form and will continue with the password check only if this form sent the correct value.

   Previous  [1]  2  3  Next