Network Computingwww.networkcomputing.com

In the January 15 issue, we discussed how using cookies stops users with the same user name and password from gaining simultaneous access to a Web server (see www.NetworkComputing.com/801/801cn1.htm).

Beyond that problem, you need to consider issues a bout basic authentication on Web servers. Intercepting and decoding user names and passwords used by browsers is a simple task for the average hacker. First, a browser sends the user name and password every time it receives a request from the server for data. This provides the hacker with multiple opportunities to catch the user name and password.

Second, the user name and password are encoded using base64 encoding, which is fully described in the Multipurpose Internet Mail Extensions (MIME) standard in RFC 1521. This form of encoding was meant for converting binary data to a form that can be sent through mail gateways (some can only handle

7-bit ASCII data). Putting data through base64 makes it look as if the data is encoded, but this protection is negligible since it can be simply decoded.

To provide any meaningful security on Web servers, you must employ cryptographic techniques, such as t he Secure Sockets Layer (SSL), Secure HTTP (S-HTTP) or Secure Electronic Transactions (SET). These protoc ols use variations of symmetric key and public key encryption and secure hashing functions. To learn more about secure protocols, see www.eit.com/creations/s-http and home.netscape.com/assist/security/ssl/index.html. These techniques rely on public and private keys that encode and decode data.

Certificates address the problem of how you can be sure the owner of a public key is who he claims to be. With certificates, the public key is packaged with other information about the sender and signed using the private key of a certifying authority. For information on implementing client-side certificates to authenticate users accessing Web servers, see "Securing Intranet Data With SSL Client Certificates," (July 1, page 82, or www.NetworkComputing. com/812/812cn2.html.

Q: I understand that CGI scripts on a server can compromise security. If I run CGI on my Web server, what measures should I take to minimize exposure?

A: Ther e are many potential security problems with running Common Gateway Interface (CGI) scripts on your server. CGI's attraction is that it lets you interact with your server, typically by completing forms. As a result, you open an entry point into your system that could be exploited in ways that are malicious. In particular, you must stop data input to forms from being passed on and interpreted as commands by another application. Commands to be wary of in CGI include eval shell; the system() and popen() C library calls; and the system(), open() and exec() Perl library calls.

In general, you should scrutinize all CGI scripts and note that compiled C language applications typically have fewer security problems than CGI scripts written with shells or interpreters. The only obvious exception is when the input buffers of C programs are overrun, causing the system to execute code imported by the overrun buffer.

At the very least, you should check the following possibilities:

· The eval script command tells the shell to interpret a string and then executes the results. If your scripts contain eval statements, check the input data before it is executed.

· Check potential loopholes in programs called from within CGI scripts. An example is standard Unix mail, which enables the execution of other programs via the ~! sequence at the beginning of a line.

· Be cautious when anonymous FTP is enabled on your Web server. It is possible for a malicious user to place a damaging file on a server using anonymous FTP and then use escape sequences in a CGI to execute it.

· Do not, as some software companies suggest you do, put a copy of

perl.exe or any other interpreter into your cgi-bin directory. (For further discussion on this matter, see w4.lns.cornell. edu/~pvhp/ perl/ntperl.html.)

If you are concerned about the security of any CGI scripts running on your system--and you should be--a tool called Latro may help (see www.perl.com/perl/news/latro-announce.html). Latro is available in the same spirit that Security Administrator Tool for Analyzing Networks (SATAN) is--not as a tool to help the bad guys, but as a way for conscientious administrators to check their systems for potential loopholes.

Since CGI security is a real concern, you should check out the following resources for further information: www.csclub.uwaterloo.ca/u/mlvanbie/cgisec, www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html and www.gt.ed.net/keith/ cgi/security.html.

Chris Lewis is vice president of international operations at ILX Systems. He is currently working in Europe. He can be reached at chrisl@ilx.com.