HTML 4.0 Sourcebook
(Publisher: John Wiley & Sons, Inc.)
Author(s): Ian S. Graham
ISBN: 0471257249
Publication Date: 04/01/98

Sending Cookies to a Server

When a browser that supports cookies accesses a URL, it checks in its cookie jar for all cookies that are appropriate to the specified domain and path. If there are no relevant cookies, the transaction proceeds normally. If there are relevant cookies, then the browser combines all the cookie name=value strings together, separated by semicolons, and modifies the request to include an HTTP request header field of the form

Cookie: name1=value1; name2=value2; ...

A CGI program parsing this request must look to the HTTP_COOKIE environment variable and extract the cookie information.

Finite Number of Cookies

Cookies do not live forever, nor do browsers support an infinite number of them; for example, Netscape Navigator allows at most 300 cookies, each cookie no longer than 4 KB. At the same time, there can be no more than 20 cookies per server or domain. If these limits are exceeded, the client will delete cookies, starting with the one least recently used. A gateway program can delete unneeded cookies by sending a new Set-Cookie header that contains an expires value that has already “expired.” This is a useful way of cleaning up cookies that are no longer required. Note that this will only work if the replacement header uses the same name for the cookie value.

Cookies and JavaScript

Cookies and cookie content can also be modified, created, or destroyed by JavaScript programs within HTML documents. This is useful for recording user actions from within navigational tools. However, a JavaScript program can only modify cookies that arrived from the same server as the JavaScript program.

Support for Cookies and Refusing Cookies

Cookies would seem an ideal way of preserving state during a transaction. This would be true—if one could guarantee that they work. However, not all browsers support cookies, while browsers that support cookies let the user disable cookie storage. Netscape Navigator, for example, can be configured to prompt the user whenever a server tries to send a cookie and gives the user the option of refusing the cookie data.

CGI Program Security Issues

There is always a security risk associated with running a gateway program, since a rogue program can easily corrupt the files located on the server. Most HTTP servers are configured such that executable CGI programs are restricted to special URLs (typically those pointing to the directories /cgi-bin or /htbin) and do not permit executable gateway programs in areas where regular documents are kept. The server administrator can then maintain strict control over the installation of gateway programs, and can verify that installed programs are not dangerous to the integrity of the server.

The details of security management depend on the server that you are using. In general, most servers allow significant customization of these features. You should check with your server manager—or with your server documentation if you are the server manager—to determine how your server can be customized.

Designing Safe Gateway Programs

Of course few people set out to write unsafe gateway programs. Nevertheless, it is easy to do so unless careful when writing the programs. Although it is hard to give definitive rules for writing safe programs, here are three points you should particularly consider:

Guard system information. Gateway programs should never return to the client any information about the local system that could compromise system security, such as absolute paths to files, system usernames, password information, and so on. If you must return directory information, pass it as a path relative to a location unknown to outside users—this reveals only limited information about the server’s filesystem.

Never trust client data. A gateway program should never trust data sent by a client—the data could be in error, either due to a simple typing mistake or due to an intentional effort on the part of the client to break into your system. As a relatively benign example, you should never blindly trust the e-mail address (either From: or To:) typed into a fill-in HTML FORM, since you could be mailing data to the wrong user, or to a nonexistent mail address.

More importantly, you should be extremely careful about using strings that are derived from user input as arguments to system calls; examples include the C or perl system() and popen() calls or the perl or shell eval commands. Blindly passing strings to these calls or commands is a classic mistake, since commands executed by these calls can easily delete files, mail your password file to a remote user, and commit other venial sins. If you must execute strings passed by the user, be sure to check them for dangerous commands and to unescape special shell characters that can cause grievous problems. The possibly dangerous shell characters are:

‘ ~ ! # $ ^ & * ( ) = | \ { } [ ] ; : ’ “ < > , . ?

Execute in a secure environment. You can often run a script under a secure or restricted shell that take proactive action to prevent problems. For example, if you are using perl gateway programs you should use taintperl instead of perl. This version of perl treats all quantities that come from environment variables or external input as tainted and refuses to pass these quantities, unprocessed, to system calls.

Chapter 11 describes some CGI programming tools that can help protect you from these sorts of security problems. However, you should still strive to design your own programs to be as secure as possible.

Server Application Programming Interfaces

The gateway mechanism is simple and effective. However, it can be slow, since the gateway program must be started up, as a distinct running process, each time it is referenced. As mentioned earlier, this is often not a problem, particularly if the resource behind the gateway program is not speedy. Nevertheless, there are many occasions when speed is of the essence and where it would be useful if the gateway designer could bypass the CGI mechanisms completely and build the interface routines directly into the server.

A few servers support this feature through custom-designed gateway application programming interfaces, or APIs. Notable among these are the Netscape Netsite server’s NSAPI (Netscape API), the Microsoft IIS Web server ISAPI, and an API under development as part of the Apache server project. The Netscape home page (http://www.netscape.com) maintains some on-line documentation on the API (just search for the string “nsapi”), but this is badly organized and poorly written (Netscape does, however, sell an NSAPI manual, should you be so bold!). On the other hand, the apache documentation site (www.apache.org/) maintains somewhat better on-line information on their own API, which is distinctly different from the Netscape variant.

Gateways built using an API are much faster than those built using the CGI interface. However, they gain this speed at the expense of portability—APIs are strongly server-specific, so if you write an API-based gateway for the Netscape Netsite server, you will be forever tied to that server as no other vendor supports that interface specification.

References

The following URLs provide documentation on CGI, Netscape cookies, and server-specific APIs. References to CGI utilities and libraries and to on-line CGI tutorials are given at the end of Chapter 11.

CGI Specification

Netscape Cookies

CGI Security

Server APIs