Login | Register | Manage

Cart Store Chat Download Clients

Server Security

Once upon a time, the World Wide Web was a relatively static place. The Web server's sole function was to simply deliver a requested Web page, written in HTML, to a client browser. Over time, developers started looking for ways to interact with users by providing dynamic content -- that is, content that displayed a form or executed a script based on user input. Thus Server Side Includes (SSI) and the Common Gateway Interface (CGI) were born.

A Server Side Include page is typically an HTML page with embedded command(s) that are executed by the Web server. An SSI page is parsed by the server (a "normal" Web page is not), and if SSI commands are found they are executed before the resultant output is delivered to the requesting client. SSI is used in situations that demand a small amount of dynamic content be inserted in a page, such as a copyright notice or the date. SSI can also be used to call a CGI script; however, there is a performance penalty associated with SSI. The server must parse every page designated as SSI-enabled, which is not an optimal solution on a heavily loaded Web server.

The CGI is a standard for communication between a program or script, written in any one of several languages, and a Web server. The CGI specification is very simple: input from a client is passed to the program or script on STDIN (standard input). The program then takes that information, processes it, and returns the result on STDOUT (standard output) to the Web server. The Web server combines this output with the requested page and returns it to the client as HTML. CGI applications do not force the server to parse every requested page; only pages containing CGI-recognized arguments involve further processing.

This article is targeted at Webmasters and system administers responsible for securing a Web server configured to provide dynamic content to clients. It details general security issues related to SSI- and CGI-enabled content, reducing CGI risks with wrappers, and some brief language-specific caveats. This article does not cover the configuration steps required to enable SSI or CGI. Configuration examples provided are based on the latest 1.3 version of Apache, which at the time of this writing is 1.3.26. In addition, the following is assumed:
Your network is secure, behind a firewall, and the server itself is in a controlled environment.
The operating system has been properly secured and all unnecessary services are disabled.
The Apache user and group directives are correctly set, and appropriate permissions assigned.
The ServerRoot and log directories are protected.
User overrides are disabled.
Default access has been disabled, and access opened for only those system directories designated "public". For example, on a system configured to host user Web pages from /home/username/public_html, Apache's httpd.conf configuration file should contain the following directives:

NetLink has good working knowledge of general Web server security, installing and configuring Apache, Apache modules, Apache's key configuration directives, the role of Apache's .htaccess file, how to read log files, UNIX file permissions, and basic system administration.