Writing Secure CGI Programs

At this point, you have presumably secured your machine and your Web serve,, You are finally ready to learn how to write a secure CGI program. The base principles for writing secure CGI are similar to the ones outlined earlier

Your program should do what you want and nothing more.
Don't give the client more information than it needs to know.
Don't trust the client to give you the proper information.

The second principle is simply an extension of a general security principle: the less the outside world knows about the inside of your system, the less equipped outsiders are to break in. This last principle is not just a good programming rule of thumb but a good security one, as well. CGI programs should be robust. One of the first things a hacker will try to do, to break into a machine through a CGI program is to try to confuse it by experimenting with the input. If your program is not robust, it will either crash or do something it was not designed to do. Both possibilities are undesirable. To combat this possibility, don't make any assumptions about the format of the information or the values the client will send.

The most barebone CGI program is a simple input/output program. It takes what the client tells it and returns some response. Such a program offers very little risk. Because the CGI program is not doing anything interesting with the input, nothing wrong is likely to happen. However, once your program starts manipulating the input, possibly calling other programs, writing files, or doing anything more powerful than simply returning some output, you risk introducing a security hole. As usual, power is directly proportional to security risk.

Different languages have different inherent security risks. Secure CGI programs can be written in any language, but you need to be aware of each language's quirks. We discuss only Perl here, but some of the traits can be generalized to other languages.

Secure Transactions

One aspect of security only briefly discussed earlier is privacy. A popular CGI application these days tends to be one that collects credit card information. Data collection is a simple task for a CGI application, but the collection of sensitive data requires a secure means of getting the information from the browser to the server and CGI program.

For example, suppose one wants to sell books over the Internet, he might set up a Web server with a form that allows customers to buy books by submitting personal information and a credit card number. After he gets the information, he would like to store it on his machine for company records.

If anyone were to break into his company's machine, that person would have access to these confidential records containing customer information and credit card numbers. In order to prevent this, he would make sure the machine is configured securely and that the CGI script that accepts form input is written correctly so that it cannot be maliciously manipulated. In other words, as the administrator of the machine and the CGI programmer,. he would have lot of control over the first problem: preventing information from being stolen directly from his machine.

However, how can one prevent someone from intercepting the information as it goes from the client to the server? Information flows over the network from the browser to the server first, and then the server passes the information to the CGI program. This information can be intercepted while it is moved from the client machine to the server. Note that in order to protect the information from being intercepted over the network, the information must be encrypted between the client and the server. You cannot implement a CGI specific encryption scheme unless the client understands it, as well.

Due to the nature of Web transactions, the only way you could develop and use your own secure transaction protocol using only CGI would be by first encrypting the form information before it is submitted by the browser to the server Consequently, securing information over the network requires modifying the way the browser and the server communicate, something that cannot be controlled by using CGI. There are currently two major proposals for encrypted client/server transactions: Secure Sockets Layer (SSL), proposed by Netscape, and Secure HTTP (SHTTP), proposed by Enterprise Integrations Technology (EIT). At this point, it is not clear whether one scheme will become standard several companies have adopted both protocols in their servers. Consequently, it ills useful to know how to write CGI programs for both schemes.

SSL SSL is a protocol independent encryption scheme that provides channel security between the application layer and transport layer of a network packet. In plain English, this means that encrypted transactions are handled "behind the scenes" by the server and are essentially transparent to the HTML or CGI author,

Because the client and server's network routines handle the encryption, almost all of your CGI scripts should work without modification with secure transactions.. There is one notable exception. An nph (no/parse/header) CGI program bypasses the server and communicates directly with the client. Consequently, nph CGI scripts would break under secure transactions because the information never gets encrypted.

SHTTP takes a different approach from SSL. It works by extending the HTTP protocol rather than a lower layer. Consequently, whereas SSL can be used for all network services, SHTTP is a Web specific protocol.

However, this has other benefits. As a superset of HTTP, SHTTP is backward and forward compatible with HTTP and SHTTP browsers and servers. In order to use SSL, you must have an SSL enabled browser and server. Additionally, SHTTP is a much more flexible protocol. The server can designate preferred encryption schemes, for example.

SHTTP transactions depend on additional HTTP headers. Consequently, if you want your CGI program to take advantage of an SHTTP encrypted transaction, you need to include the appropriate headers. For example, instead of simply returning the HTTP header

Content Type: text/html
you could return
Content Type: text/htmI Privacy Enhancements: encrypt

When an SHTTP server receives this information from the CG I application, it will know to encrypt the information before sending it to the browser. A non SHTTP browser will just ignore the extra header.

Domain Name Search