Password Capture on NT Intranets Using Basic Authentication

By Randy Steer

There's an interesting security hole tied to CGI on Windows NT Web servers when they require users to log in. If the webserver is used as an intranet in an office network, it is likely that access to the intranet is restricted to certain categories of users. One of the most common ways of doing that is to require users to log onto the webserver using "basic authentication" and then to have the server check with a trusted domain controller to see if the username and password are valid.

System Variables Contain Usernames and Passwords

What's not obvious is that your browser retains the username and password and re-transmits them with each subsequent HTTP request. Both entries are accessible to the CGI interface as plain text, as the system variables "AUTH_USER" and "AUTH_PASSWORD." These can be accessed by Perl scripts, and are also available to ColdFusion as system variables #auth_user# or #cgi.auth_user# and #auth_password# or #cgi.auth_password#. Actually, the password may not always be available to ColdFusion -- when I tested this before, CF was able to provide a value for #auth_user#, but not #auth_password#. Now it's providing both. I have no explanation for why the behavior changed, however. The only change to the server was a reinstallation of CF (we have version 4.01) and NT Service Pack 4 -- the same setup as before. (Periodic reinstallation seems necessary because the remote administration facility keeps getting corrupted.)

The accessibility of "AUTH_USER" and "AUTH_PASSWORD" is both good news and bad news. The good news is that you can automatically identify a user each time they open a page on the intranet, without cookies. This permits customization and fine-grained access control for databases. (For instance, a personnel directory can display an "Edit" button when a user displays their own entry in the database, but not at any other time.) The bad news is that any CGI or ColdFusion author permitted to place scripts on the intranet could include a brief routine to log usernames and their associated passwords into a database or text file.

I've tested this with both Netscape 4.08 and IE 4.0, the standard installations in my agency. Since the basic authentication (and setting the system variables) is done by the server, and only requires the browser to be able to understand and handle password requests from the server, the effect probably exists with any browser. I've only been able to test it on the server software we run for our intranet, which is IIS 4.0, running on an NT 4.0 server with service-pack 4.

The problem does not appear to exist if the website is set up to use NT challenge-response authentication and the clients are using MS IE, which supports that method of authentication (I think in versions 3.0 and later). Under those conditions, my password variable was reported simply as ".".

Greater Risk with ColdFusion Than with CGI

This is even more problematic with ColdFusion than with CGI. CGI scripts are usually confined to one branch of the directory tree, making it relatively easy to look for this type of code and making it easier to restrict write-access to the CGI directory. ColdFusion is easier to author, so an intranet is likely to have many more people building ColdFusion pages than CGI scripts. The pages can be anywhere on the directory tree, making it harder to search for malicious code.

I haven't found any way around this, as long as a website requires a login with the user's NT username and password. The only controls one can impose are human ones: restrict who can author CGI and ColdFusion scripts, and search scripts and ".cfm" files for key text strings like "auth_password" that would have to occur if a malicious script routine was embedded.

Long-term solutions would have to come from Microsoft and Allaire -- giving system administrators the option of telling the CGI gateway not to reveal the value of "AUTH_PASSWORD" or telling ColdFusion to treat "#auth_password#" as undefined.

• Subscribe
• RSS

• Editorial
• Specials
• Community
• News
• Tech and Tags
• Views
• Reviews
• Techniques
• Security
• Best of ColdFusion Talk
• Knowledge Base
• Blog Watch

• Tipical Charlie