Chapter 9: CGI Security    (01)

<Next | Table of Contents | Previous>    (02)

Secure Transactions    (03)

One aspect of security I 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.    (04)

For example, suppose that I want to sell books over the Internet. I 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 I have that information, I would want to store it on my machine for company records.    (05)

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

However, how can I prevent someone from intercepting the information as it goes from the client to the server? Remember how information moves from the Web browser to the CGI program (as explained in Chapter 1, "Introduction to CGI")? 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 (as shown in Figure 9.2). 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.    (07)

Figure 9.2. A diagram of the information flow between the client, server, and CGI application.    (08)

Java, CGI, and Secure Transactions    (09)

Due to the nature of Web transactions, the only way you could develop and use your own secure transaction protocol using solely CGI would be by first encrypting the form information before it is submitted by the browser to the server. The scheme would look like the diagram in Figure 9.3.    (010)

Until recently, developing your own secure transaction protocol was an impossible task. Thanks to recent innovations in client-side processing such as Java, such development is now possible.    (011)

The idea is to create a Java interface that is a superset of normal HTML forms. When the Java Submit button is selected, the Java applet would first encrypt the appropriate values before sending it to the Web server by using the normal POST HTTP request (see Figure 9.4).    (012)

Using Java as a client to send and receive encrypted data enables you to create your own customized encryption schemes without requiring a potentially expensive commercial server. For more information on how one might implement such a transaction, refer to Chapter 8, "Client/Server."    (013)

Figure 9.3. A secure transaction scheme using only CGI.    (014)

Figure 9.4. An applet sends the form data instead of the browser.    (015)

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 is useful to know how to write CGI programs for both schemes.    (016)

SSL    (017)

SSL is a protocol-independent encryption scheme that provides channel security between the application layer and transport layer of a network packet (see Figure 9.5). 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.    (018)

Figure 9.5. The SSL protocol providing secure Web transactions.    (019)

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. A notable CGI application that is affected by this problem is Netscape server-push animations (discussed in detail in Chapter 14, "Proprietary Extensions"). I doubt this is a major concern, however, because it is highly likely that an animation is expendable on a page for securely transmitting sensitive information.    (020)

SHTTP    (021)

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

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.    (023)

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    (024)

Content-Type: text/html    (025)

you could return    (026)

Content-Type: text/html
Privacy-Enhancements: encrypt    (027)

When an SHTTP server receives this information from the CGI application, it will know to encrypt the information before sending it to the browser. A non-SHTTP browser will just ignore the extra header.    (028)

For more information on using SHTTP, refer to the SHTTP specifications located at <URL:http://www.commerce.net/information/standards/drafts/shttp.txt>.    (029)

<Next | Table of Contents | Previous>    (030)

Copyright © 1997 Sams.Net Publishing    (031)