Guidelines on Securing Public Web Servers

Most Web server software vendors provide directives or commands that allow the Web 

administrator to restrict user access to public Web server content files.  For example, the 

Apache Web server software provides a Limit directive, which allows the Web administrator 

to restrict which optional access features (such as New, Delete, Connect, Head, and Get) are 

associated with each Web content file.  The Apache Require directive allows the Web 

administrator to restrict available content to authenticated users or groups. 

Many directives or commands can be overridden on a per directory basis.  The convenience of 

being able to make local exceptions to global policy is offset by the threat of a security hole 

being introduced in a distant subdirectory, which could be controlled by a hostile user.  The 

Web administrator should disable a subdirectory's ability to override top level security 

directives unless that override is absolutely necessary. 

In most cases, Web server file directory listings should be disabled.  The HTTP specifies that a 

URL ending in a slash character be treated as a request for a listing of the files in the directory 

with that name.  Web servers should be prohibited from responding to such requests, even if 

the public can read all of the directory files.  Such requests often indicate an attempt to locate 

information by means other than those intended by the Web administrator or Webmaster.  

Users may attempt this if they are having difficulty navigating through the site or if a link 

appears to be broken.  Intruders may attempt this to locate information hidden by the Web 

site s interface.  Web administrators should investigate requests of this type found in the Web 

server log files (see Section 7). 

5.2.3  Uniform Resource Identifiers and Cookies 

Uniform Resource Identifiers (URIs) are the address technology from which URLs are 

created.  Technically URLs (e.g., 

http://www.mywww.gov

) are a subset of URIs.  There are a 

number of security issues that arise from URIs.  Since URIs are sent in the clear, any data that 

is stored within them can be easily compromised.  For example, URIs are recorded in 

numerous location including Web browser logs (i.e., browser history), proxy server logs, and 

third party HTTP referrer logs.  Thus hiding sensitive data such as usernames and passwords, 

or hidden server resources in URI is not recommended.  Security through obscurity is not 

secure.   

URIs are often included with public web content.  Although those these URIs may not display 

as Web content in a user's Web browser, they can be easily discovered in the source code.  

Therefore no publicly served Web content should include sensitive URI hidden in the source 

code.  Many attackers and malicious bots (see Section 5.2.4) will search the source code for 

sensitive URI information including: 

E mail addresses 

Images on other servers 

Links to other servers 

Particular text expressions (e.g., userid, password, root, administrator) 

Hidden form values 

Hyperlinks 

31