Operating systems
Although the Unix and NT communities may not like to hear it. In general, the more powerful and flexible the operating system, the more open it is for attack through its Web (and other) servers.
Unix systems, with their large number of built-in servers, services, scripting languages, and interpreters, are particularly vulnerable to attack because there are simply so many portals of entry for hackers to exploit. Less capable systems, such as Macintosh and special-purpose Web server boxes, are less easy to exploit. The safest Web site is a bare-bones Macintosh running a bare-bones Web server.
In the real world, of course, many sites will want to run a Windows NT or Unix server in order to gain the performance advantage of a multitasking operating system and the benefits of database and middle ware connectivity . Security holes have been found in both Unix and Windows NT server systems, and new security holes are being found on a regular basis. On the whole Windows NT systems seem to be more vulnerable at the current time, partly the OS is relatively new and the big bugs haven’t been shaken out, and partly because the NT file system and user account system are highly complex and difficult to configure correctly.
If you have configured your system correctly and are compulsive about applying your vendor’s security patches promptly, a typical Unix system will be more secure than a typical NT system. However, you also have to factor in the experience of the people running the server host and software. A Unix system administered by a novice system administrator will be far less secure than an NT system set up by a seasoned Windows NT system administrator.
Server software programs
As a rule of thumb, the more features a server offers, the more likely it is to contain security holes. Simple servers that do little more than make static files available for requests are probably safer than complex servers that offer such features as on-the-fly directory listings, CGI script execution, server-side include processing, and scripted error handling.
Version 1.3 of NCSA’s Unix server contains a serious known security hole. Discovered in March of 1995, this hole allows outsiders to execute arbitrary commands on the server host. If you have a version 1.3 httpd binary whose creation date is earlier than March 1995 don’t use it! Replace it with the patched 1.3 server (available at http://hoohoo.ncsa.uiuc.edu/) or with version 1.4 or higher (available at the same site). The Apache plug-in replacement for NCSA is also free of this bug.
Servers also vary in their ability to restrict browser access to individual documents or portions of the document tree. Some servers provide no restriction at all, while others allow you to restrict access to directories based on the IP address of the browser or to users who can provide the correct password. A few servers, primarily commercial ones (e.g. Netsite Commerce Server, Open Market), provide data encryption as well.
The WN server, by John Franks, deserves special mention in this regard because its design is distinctively different from other Web servers. While most servers take a permissive attitude to file distribution, allowing any document in the document root to be transferred unless it is specifically forbidden, WN takes a restrictive stance. The server will not transfer a file unless it has been explicitly placed on a list of allowed documents. On-the-fly directory listings and other “promiscuous” features are also disallowed.
A table comparing the features of a large number of commercial, freeware and public domain servers has been put together by the WebCompare site:
Scripts
CGI scripts are a major source of security holes. Although the CGI (Common Gateway Interface) protocol is not inherently insecure, CGI scripts must be written with just as much care as the server itself. Unfortunately some scripts fall short of this standard and trusting Web administrators install them at their sites without realizing the problems.
Server side script includes, snippets of server directives embedded in HTML documents, are another potential hole. A subset of the directives available in server-side includes instruct the server to execute arbitrary system commands and CGI scripts. Unless the author is aware of the potential problems it’s easy to introduce unintentional side effects. Unfortunately, HTML files containing dangerous server-side includes are seductively easy to write.
Some servers, including Apache and NCSA, allow the Web master to selectively disable the types of includes that can execute arbitrary commands. Versions of NCSA httpd prior to 1.4 contain a serious security hole relating to a fixed-size string buffer. Remote users could break into systems running this server by requesting an extremely long URL. Although this bug has been well publicized for more than a year, many sites are still running unsafe versions of the server. The current version of the software, version 1.5, does not suffer from this bug and is available at the link given at the beginning of this paragraph.
Recently it has come to light that example C code (cgi_src/util.c) long distributed with the NCSA httpd as an example of how to write safe CGI scripts omitted the newline character from the list of characters that are shouldn’t be passed to shells. This omission introduces a serious bug into any CGI scripts that were built on top of this example code: a remote user can exploit this bug to force the CGI script to execute any arbitrary Unix command.
In addition, the NCSA server source code tree itself contains the same bug (versions 1.5a and earlier). The faulty subroutine is identical, but in this case is found in the file src/util.c as opposed to cgi_src/util.c. After looking through the server source code, I haven’t found a place where a user-provided string is passed to a shell after being processed by this subroutine, so I don’t think this represents a actual security hole. However, it’s best to apply the patch shown below to be safe.
The Apache server, versions 1.02 and earlier, also contains this hole in both its cgi_src and src/ subdirectories. It’s not unlikely that the same problem is present in other derivatives of the NCSA source code.
The patch to fix the holes in the two util.c files is simple. “phf” and any CGI scripts that use this library should be recompiled after applying this patch (the GNU patch program can be found at ftp://prep.ai.mit.edu/pub/gnu/patch-2.1.tar.gz). You should apply this patch twice, once while inside the cgi_src/ subdirectory, and once within the src/ directory itself:
tulip% cd ~www/ncsa/cgi_src
tulip% patch -f < ../util.patch
tulip% cd ../src
tulip% patch -f < ../util.patch
------------------- cut here -------------------
*** ./util.c.old Tue Nov 14 11:38:40 1995
--- ./util.c Thu Feb 22 20:37:07 1996
***************
*** 139,145 ****
l=strlen(cmd);
for(x=0;cmd[x];x++) {
! if(ind("&;`'\"|*?~<>^()[]{}$\\",cmd[x]) != -1){
for(y=l+1;y>x;y--)
cmd[y] = cmd[y-1];
l++; /* length has been increased */
--- 139,145 ----
l=strlen(cmd);
for(x=0;cmd[x];x++) {
! if(ind("&;`'\"|*?~<>^()[]{}$\\\n",cmd[x]) != -1){
for(y=l+1;y>x;y--)
cmd[y] = cmd[y-1];
l++; /* length has been increased */
------------------- cut here -------------------