When tightening security on an Apache server, you should examine the use of CGI (Common Gateway Interface). It stands to reason that a leak in an application occurs at the point at which the users' fingers touch the database, and CGI is that point. It is the bridge between the Web server and external programs, telling the server how to execute those programs to fulfill browser requests. CGI controls data formatting in both directions. It's a protocol, not a language, and can be implemented in many ways.
Finding security holes
A big problem with CGI scripts is that the server defaults are easy to exploit. Here are a few of the most dangerous ones:
- Running as the Web server user. By default, all CGI scripts run as the same user—the Web server itself. Although that seems like a security nightmare, it makes sense. CGI scripts control user interaction with the server, so those scripts require different file permissions. It's simpler, when defining a default, to give all scripts the file permissions of the Web server itself and to allow the administrator to limit them application-by-application. The problem is, the administrator never ends up doing it.
- The script directory is easily found. Scripts are easily accessed and manipulated. The default location of a server's CGI scripts is cgi-bin. If a hacker knows where the scripts are, you've given away the keys to the kingdom.
- Extensions are dead giveaways. By default, CGI scripts have a .cgi extension. That is, the Apache server treats all files with this extension as CGI. So if the server's handling of the .cgi extension is server-wide and not confined to specific directories, a hacker can run powerful unauthorized CGI scripts without administrator permission.
Wrapped up tight
CGI scripts are embedded in Web applications and escort the user directly into the server's inner sanctum, where they have permissions and server resource access that may be seized and abused by a malicious user. But you can add a layer of protection by placing any CGI script in a wrapper that insulates it, and hence the application and the user, from server goodies that can be exploited. Permissions and resources that were necessarily accessible to the CGI script may be manipulated for the wrapper. A hacker has only the power bestowed by the wrapper, not the script.
suEXEC solves most of your problems
Switch User for Exec (suEXEC) is an administrative tool that addresses many CGI hazards. It empowers the server administrator to run CGI scripts as users other than the Web server user. A user's program will run under his or her ID. Applications employing CGI scripts can be confined to their specific user's environment.
This takes you around the permissions problem. You've effectively created a wrapper that isolates the user from root-privilege permissions. In addition, a suEXEC wrapper runs security checks every time a script is run, actively validating the program call, the user, file location, and permissions, all of which the administrator defines.
suEXEC is part of Apache and has been since 1.2. From 1.3.x forward, its enabling is handled as part of Apache configuration, before you type the following command:
Assigning a name and directory (other than user directories) is simple:
suexec-docroot=DIR (default is htdocs)
You can set other parameters to increase user ID security. These include setting a valid file path, user ID limitations, and valid user home directories. Consult your documentation for details.
Other CGI wrappers
A library-based wrapper called FastCGI might also be the way to go. It's more of a developer-oriented hedge against hackers than an administrator's tool. FastCGI extends the CGI specification by providing an environment that includes secure I/O routines to plug into your apps. This allows the developer to focus on tightening up the CGI script in other ways, such as fine-tuning its memory segment usage so that it can't be misused.
CGIWrap forms an additional layer between the Web server and executing program, similar to suEXEC in many respects, such as running CGI scripts as a non-Web server user. It also performs security checks with each run.
Using an alias
You can thwart a malicious user seeking to access your CGI scripts by obscuring the location of the directory that holds them. That directory is cgi-bin, and the server won't execute a CGI script unless it is in that directory. But with an alias, you can hide it. You do this in the config file httpd.conf:
ScriptAlias� /cgi-bin/� "/alternate_directory/cgi-bin/"
You're giving the server permission to treat files in this alternate directory as CGI scripts, where normally it would accept files only in the cgi-bin directory. Be sure to restrict user access to this directory; otherwise, users could put a CGI script of their own devising—one with root privileges—into the directory, where the server will be happy to permit it to execute.
What's in a name?
Another CGI default is that the server will passively assume that any CGI script (i.e., a file with a .cgi extension) should be enabled in all Web server-accessible directories. (This is the case only if you've enabled the handler that identifies CGI scripts in this manner; it's in httpd.conf.)
It's easy to make CGI execution directory-specific rather than server-wide. Simply add ExecCGI to the Options for each directory that you want to have the power to execute them. In this way, you restrict the I/O and resource allocation power of CGI scripts to specific users and applications. Remember that this feature can cut both ways, and careless use can enable hackers as effectively as its appropriate use can disable them.
Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence and social informatics, primarily in the health care and HR industries.