Guidelines on Securing Public Web Servers

Database access 

E commerce/E government applications 

Chart rooms 

Threaded discussion groups. 

The server side applications can be written in many programming languages to run on a Web 

server.  If scripts are not prepared carefully, however, attackers can find and exercise flaws in 

the code to penetrate a Web server.  Therefore, scripts must be written with security in mind 

and, for example, should not run arbitrary commands on a system or launch insecure 

programs.  An attacker can find flaws through trial and error and does not necessarily need the 

source code for the script to uncover vulnerabilities [NIST01a]. 

Server side content generators can create security vulnerabilities at the server: 

They may intentionally or unintentionally leak information about the Web server 

application and host operating system that can aid an attacker, for example, by 

allowing access to information outside the areas designated for Web use. 

When processing user provided input, such as the contents of a form, URL 

parameters, or a search query, they may be vulnerable to attacks whereby the user 

tricks the application into executing arbitrary commands supplied in the input stream. 

Allow attackers to deface or modify site content. 

Ideally, server side scripts should constrain users to a small set of well defined functionality 

and validate the size and values of input parameters so that an attacker cannot overrun memory 

boundaries or piggyback arbitrary commands for execution.  A script should be run only with 

minimal privileges (i.e., non administrator) to avoid compromising the entire Web site.  

However, potential security holes can be exploited, even when applications run with low 

privilege settings so this option should only be used as a last resort.  For example, a subverted 

script could have enough privileges to mail out the system password file, examine the network 

information maps, or launch a login to a high numbered port. 

The areas of vulnerability mentioned potentially affect all Web servers.  Although these 

vulnerabilities have frequently occurred with CGI applications, other related interfaces and 

techniques for developing server applications have not been immune.  CGI, being an early and 

well supported standard, has simply gained more attention over the years, and the same areas 

of vulnerability exist when applying similar Web development technologies at the server. 

Common Gateway Interface (CGI)

   CGI scripts have been the initial mechanism used to 

make Web sites interact with databases and other applications.  However, as the Web evolved, 

server side processing methods have been developed that are more efficient and easier to 

program, for example, Microsoft ASPs for its IIS servers, Sun/Netscape supports Java servlets, 

and the freeware PHP is supported by on most major Web platforms, including Apache and 

IIS [NIST01a].  Some issues to consider when contemplating the deployment of CGI [Zir02]: 

Host file system (see Section 4.1) provides security for CGI. 

44