Protecting Sensitive Data

One of the most common uses for CGI is to offer real time data from a database to users. For example, an airline could create a CGI that queries a reservation database in real time and returns a list of available flight options. If the machine is compromised, the entire database might be obtained by the intruder; or worse, its contents could be maliciously altered, causing untold damage.

This is a difficult situation. Presumably if someone breaks into the machine, he or she has at least the privileges of the CGI or server through which access was obtained. This means that whatever privileges the CGI had with regard to the data, the cracker now has as well. In this situation the aforementioned precautions to minimize vulnerability hold greater importance.

If possible, nothing should have write access to the database. It can be further protected by placing it on a separate machine and allowing the CGI to query it only via the network. This can be used to constrain the capability of the server machine to obtain data and to prohibit anyone from gaining a full database dump. The setup would look like figure 14.2.

Figure 14.2  Placing the database on another machine.

If the database server portions out data only in response to specific queries, extracting a large amount of data is arduous.

Whatever precautions are taken, allowing WWW access to a database carries risk to the privacy of the stored data—and if write access is possible, to its integrity. An organization should weigh carefully whether the perceived benefits of real time access are sufficient to render the risk acceptable.

Logging

Unless configured otherwise, the HTTP server logs all requests, including those to CGIs. However, this is of limited utility in identifying and diagnosing attacks, because in POST requests the submitted data is not logged by the server.

The CGI can print its own error messages, either to the server error log or to a separate one. Error conditions that indicate a possible attempt to breach security should always be logged, along with as much information about the originating request as possible. A request containing binary data when none is expected might be an attempt to exploit a buffer overrun. A request containing shell metacharacters and commands to execute is almost certainly an attempt to exploit a lazy script.