Server-Side Risks

Once placed on a network, a server is vulnerable to attack. When placed on a public network, such as the Internet, a server is even more likely to be attacked. The major goal of an attack is to either gain control of the server or extract valuable information from it. Achieving the first will make achieving the second trivial.

The specific risks of Web application serversthose processing HTTP Web requestsare like those for most systems and relate to improper configuration, or bugs, in the software. A cracker will exploit a bug in a server's software or an improperly configured system. The most common configuration mistakes involve the enabling of optional features not required for the application. For example, one common feature of a Web server is directory browsing. This feature allows anonymous users to examine the contents of whole directories on the Web server instead of only the contents of the files it is supposed to serve.

A cracker uses as much information as can be obtained about a system to break into it. The more information a cracker has, the more likely that the system can be cracked. Allowing directory browsing gives the potential cracker more information about the system. This information can include backup files of sensitive scripts that contain source code to the applications modules.

EMACS, the popular UNIX-based editor, by default maintains a backup copy of files that it is working on, usually in the directory where the original file exists. A sloppy developer might have used EMACS to correct a bug in a CGI Perl script on the production machine and forgotten to remove the EMACS-generated backup file. Recognizing this file in a directory listing of the CGI directory, a cracker would examine it. The file contains source code to the application and valuable information about the Web application's server-side resources.

Allowing the use of symbolic links to directories elsewhere in the system is another dangerous feature. Symbolic links, such as /etc, to sensitive areas of a server are very dangerous. Unless the application requires the use of symbolic links, it is best to keep this feature turned off.

Another major security hole is the use of server-side includes (SSI). An SSI is a directive that is embedded in an HTML page. When a user requests this page, the Web server processes the embedded command(s) before sending back the HTML page. Some server-side includes allow the execution of general operating system commands or scripts. These "exec"-style directives are a major security hole and should be allowed only when absolutely necessary. They open up the possibility of an attacker's embedding a command that might e-mail out the system's password file or do other forms of malicious damage.

In addition to improperly configured servers, bugs in the Web server and associated softwareeven including the operating system itselfare a major security risk. Take, for example, one of the early versions of Microsoft's IIS and Active Server Pages running on a Windows NT 4.0 server. When the Web server used an NTFS-formatted file system, partition clients could request the source code to all the ASPs by simply appending :$DATA to a Web page request. In fact, clients could even request the raw contents of the special application configuration file (global.asa). This particular file often contains important configuration information normally hidden to users of the application.

One of my first ASP commerce applications was susceptible to this bug. My jaw virtually dropped to the floor when a friend, who had been notified of this bug when the word first went out, e-mailed me the contents of my global.asa file, which contained important information on the structure of my application. Of course, the first thing I did was to navigate to the Microsoft Web site: http://www.microsoft.com/default.asp:$DATA. For the next 36 hours, the entire ASP development community was abuzz in activity; by the time the fix came out from Microsoft, we had all come to the collective realization that none of us could write decent code. Fortunately, neither that file nor the contents of other dynamic files in the system alone were sufficient to allow the novice cracker unwanted access to the system. But the mere fact that the information was available was dangerous to the security of the system. Even before the official patch came out, several workarounds had been posted to the Net immediately after the bug was publicly known.

When a company makes its first plunge into the world of Internet commerce, the question that is often asked is: Are some operating systems and Web servers more secure than others? The simple answer is yes, qualified with "at any given time." It is impossible to say which operating systems are the most secure at this moment; things could be completely different in a few months. In general, the older and more stable the operating system is, the more secure it is because most of the obvious bugs have been discovered and patched. Of course, with each patch comes the potential for newer bugs and incompatibilities to be introduced. This cycle of operating system patch and upgrades eventually leads to a refinement of the system, ideally one with greater stability. Unfortunately, the cycle resets itself each time a new set of features, or a significant upgrade, is introduced.