There are so many ways to hack into a server that just a few moments of contemplation can send an administrator into a deep depression. Fortunately, perseverance in finding the possible holes is well rewarded. One hole you may not have thought of is the Common Gateway Interface (CGI) program.
CGI is the popular standard for generating content dynamically on the server side. Web apps are increasingly dynamic these days, so there are CGI-based applications everywhere—and you are almost certainly running CGI apps on your server. If so, you may have a problem. This article will examine some of the security issues associated with CGI programs.
First in a series
This is the first installment in a series of articles on Apache and Web server security. Other articles will discuss preventing DoS attacks, creating CGI wrappers for applications, and intrusion detection.
The World Wide Web Consortium produced CGI, a protocol that enables the dynamic creation of Web-accessible content. It builds a communications pathway between external programs and your Web server. The CGI specification tells the Web server how to execute external programs to fulfill a browser request. The formatting of data traveling in both directions in response to the browser request is also defined by this specification. CGI is not an API, and you can implement it with most of the popular languages, such as C++, Java, Perl, and PHP.
Hackers use CGI programs by cracking them and setting up some process of their devising to run on your server with root privileges. By exploiting sloppy memory allocation by a CGI program, they can insert and execute malicious code. These and other CGI weaknesses open a Pandora's Box of security problems.
CGI: Form and content
To understand how a hacker can use a CGI program against you, you need to know how CGI normally works on your server. A typical occurrence of its use is the interaction between a Web app and a user via a form.
Forms are usually handled in HTML, such as the name/address/phone form that pops up when you order something from a Web site. When the form is submitted, the browser pulls the data from the form, formats it, and sends it to a predefined URL. A CGI program is defined in the HTML code. The server knows by that URL whether to run the program and will accordingly hand off the form input. The CGI program then validates the data, noting errors (forwarded back to the browser). In this manner, the CGI program acts as front-end to whatever database system the user is interacting with.
CGI is easy to use, versatile, and infinitely more convenient than handing off its functions in either direction. And it is a short leap from the CGI form discussed above to entire systems of CGI programs, fronting complex order processing systems and electronic commerce systems.
Because CGI is so convenient as a front-end for applications that interact with databases, it has a lot of flexibility and power that can go awry. Here are some examples of how these capabilities can be exploited if a CGI script is badly written:
When a CGI script is executed, it normally has the privileges of the user represented by the running Web server—and that user probably has root privileges. This being the case, why does the CGI script also have the same privileges? To avoid the bottleneck of a CGI script (which is fronting for the database) being unable to execute the same file operations that the Web server can execute. Hackers know that if they can seize control of a CGI script, they have access to root privileges.
Since CGI scripts are often so incidental, and even trivial, little effort goes into correct allocation of memory segments. Seizing control of a CGI script gives the hacker access to server memory resources that may be arbitrarily used for the execution of malicious code.
It's up to the programmer who writes a CGI script to determine how rigorously input must be screened. Remember that a CGI script is often used to escort input directly from a user into the inner sanctum of a Web server. If the input validation and verification of the CGI script is missing or badly written, a hacker can manipulate the script to grab memory for the execution of an unauthorized program.
Wrap it up
These are serious deficiencies, and the latitude they give a hacker is formidable. It's enough to make you question the use of CGI altogether—but to abandon CGI would be to abandon one of your most powerful Web application assets. So what do you do?
Unlike many hacker-exploitable weaknesses in Web technology, CGI programs have a fix that works wonderfully. You can create a "wrapper" for your CGI programs, a container that preserves all of CGI's strengths and removes the weaknesses. Here's what a CGI wrapper offers:
- Control of access to system resources. A CGI wrapper can limit the memory available to the script and prevent any unauthorized code from accessing the server file system or CPU. The hacker is stopped in his tracks.
- Isolation of users. To overcome the permission-sharing between the CGI script and the Web server user identity, the wrapper can ensure that ownership of an executing process doesn't change; root privileges won't be improperly assigned.
CGI wrappers are inserted between the CGI script and the server administration software. They change the user and group identity so that the script runs independently of the server administrator's identity. And since each CGI script running on the server is independently defined, all user CGI scripts are isolated from each other. There's nowhere for a hacker to go.
Which CGI wrappers are available to you depends largely upon the server administration software you're using. But there are several types of wrapper, each with powerful features. Examine these carefully to see which is right for your environment.
CGI module wrappers
CGI module wrappers regulate interaction with the server's execution environment. The CGI script's exchange with the server can be more versatile, giving the script greater potential functionality. You can also implement session tracking with module-based wrappers.
Nested CGI programs
It's possible to create a CGI wrapper from a CGI program. Basically, the server executes the wrapper, and the wrapper executes the script. The wrapper's function can be to control system resources, with the restrictions applied to the embedded CGI script. So a hacker who seizes control of the CGI script will be boxed in.
Library CGI wrappers
CGI libraries may be used to control CGI I/O. The advantage here is that CGI I/O can be handed off to routines that are rigorously, rather than casually, developed, with proven robustness. In addition, handing this huge portion of a CGI program off to secure, predefined components gives the CGI programmer more time to focus on diligent development of the remainder of the program, such as prudent resource allocation.
Learn more about CGI and security
For more information about CGI scripting and security issues in general, the World Wide Web Consortium provides an informative page. Included on the page are sections on client- and server-side security, protecting confidential documents, and denial of service attacks.
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.