Password Protect Your IIS 5.0 Web Pages

Java, ASP, or Windows: Discover the best way to secure your 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.

Insert the code in Listing 2 at the top of an existing page followed by your existing HTML and tags or the ASP code. Give the page the same name as defined in the POST action= filename method, which in this case is protect.asp. Then, you can change the password in the If Password= string to your selection. Because the ASP code is server-side code, the password won't be exposed to the user's browser. Be sure not to let users browse this directory because they'll be able to right-click the filename and save the entire contents to a local disk. After users have saved the file locally, they can display the file's contents, including the ASP code and password. If the user enters an incorrect password, the form will continue to reappear, which is preferable over the error message 404 File not found or a Maximum Retries Exceeded error. After the user has entered the correct password, the code redirects the user to the protected portion of the page.

Another method of ASP password protection is to use a password database or password file. This technique presents a form page that requests a username and password from the user. The system compares the username and password with entries in a database or parses a password file for a match. This method is generally more secure than the examples I gave earlier because the ASP code and passwords are stored in separate locations. Many examples of ASP scripts that use a password database are available at ASP code repositories on the Internet.

One final consideration is that you can't let users simply bypass the authentication pages, which means that pages must execute in a controlled order if they don't contain forms that submit to themselves. To prevent this bypass, use session variables or session cookies, and set the page to expire immediately so that the ASP code executes each time the page is accessed. Not doing so might let subsequent users use a cached version of the page to gain access. Caching is one disadvantage of using a session variable: The session stays active until the browser window closes, and anyone who uses the open window can continue to access the secure page.

Using Built-in Windows and IIS Security
Both the JavaScript and ASP code samples are easy to implement, but you can password-protect your Web pages just as easily by using built-in Windows and IIS security features. In a few minutes' time, you can employ user accounts and passwords from the local SAM database to protect chosen pages. In the case of a Win2K system, you can also employ user objects from Active Directory (AD). Windows filesystem security inherently handles all problems with page or file protection and page execution order.

You set up these authentication methods in Microsoft Management Console (MMC). To set up authentication, follow these steps:

Before you begin password-protecting your Web pages, note that the disk on which password-protected files and directories reside must be NTFS. You need to verify that the wwwroot partition, in addition to any virtual directories that use IIS password protection, is NTFS. To password-protect your files and applications, follow these steps:

Next, you need to set the IIS permissions for Web access. Open MMC, then expand Services and Applications, Internet Information Services, and the Web site to which you're applying password protection. Right-click the directory or file to which you want to apply password protection, then select Properties. If you're disabling Anonymous access for all files in a directory, right-click that directory in MMC's left pane, then select Properties. Click File Security, then click Edit. To force IIS to present a password dialog box to the user, clear the Anonymous access check box in the Authentication Methods dialog box, then select the Basic authentication (password is sent in clear text) check box. By making these two modifications, browsing users are no longer masquerading as the IUSR_computername user to gain access; users will have to authenticate to open the file or directory.

If your users are logging on to a domain and running Microsoft Internet Explorer (IE), you also have the option of selecting both Basic authentication and Integrated Windows authentication. Doing so lets authenticated IE users pass an encrypted username and password to gain access without a dialog box appearing. (The system still prompts Netscape users for a username and password.) However, if the protected page is the entrance to a database update form or secure application, having a dialog box appear to the user is a nice visual queue that he or she is entering a controlled area. The dialog box also prevents another user from using someone else's authenticated station to access the page or program.

To complete the password-protection setup process, open the Control Panel Local Security Policy applet. Expand Local Policies, then expand User Rights Assignment, as Figure 3, page 16, shows. Double-click Log on locally. Make sure that the user or group to whom you've granted access to the password-protected files has the Log on locally right. If the user or group isn't displayed, click Add, then select the user or group. The user or group will appear in the Assigned To window with the Local Policy Setting selected.

The password-protection setup procedure is now complete, and you can test the access security for a password dialog box. Be certain that all sensitive pages--not just the menu page that requests a password--are protected from viewing by an unprivileged user. If this menu page links to a database form page and a user knows the URL, that user might be able to skip directly to the form page with no authentication.

To ease the administration of protected-page security, use a group and add all authorized users to this group. You also have the option of granting access to only one user account, then supplying this username and password to a team or department of users. In addition, consider disabling IE's password-caching feature so that users can't select the Save this password in your password list check box. For information about this procedure, see the Microsoft article "How to Disable Internet Explorer Password Caching" (http://support.microsoft.com/support/kb/articles/q229/9/40.asp).

The IIS Advantage
Using integrated IIS security has advantages over both programmatic methods for securing Web pages. With integrated security, page execution order isn't important as long as all sensitive pages are protected. In addition, users need to enter their passwords only once, and you don't need to use session cookies or monitor a session variable. Finally, you can easily control user access by using individual accounts, groups, and NTFS security, and you don't have to add code or include files to secure pages.

Note: The steps for password-protecting files or applications are for a Win2K Server or Win2K Advanced Server installation. The dialog boxes and check boxes are slightly different for Windows NT 4.0 and IIS 4.0. For example, in IIS 4.0, when you right-click the file or directory you want to protect, you'll select Properties, Security, then click the Permissions tab. On this tab, verify that the Administrator group has Full Control, then remove the Everyone and IUSR_computername groups as in the IIS 5.0 process. Then, add the users or groups that you want to have access to the protected file, directory, or application. If this directory is the one that you're protecting, select the appropriate check boxes that control the propagation of the permissions to the files and subdirectories.

Note: You select Basic authentication with clear text so that the authentication prompt dialog box will appear to Netscape users and they can authenticate successfully. Of course, a security risk exists in selecting Basic authentication because the password is passed as clear text. If the server in question is on a public network, I discourage this configuration.