Guidelines on Securing Public Web Servers

Excellent performance. 

Highly configurable which may make it difficult for novices to secure. 

Much of the freely available third party code for PHP is poorly written from a security 

perspective.

23

6.3.3  Server Side Content Generator Security Considerations 

When examining or writing an active content executable or script, consider the following 

questions: 

Ensure that the executable code is as simple as possible.  The longer or more complex 

it is, the more likely it is to have problems.  

Limit the executable code's ability to read and write programs.  Code that reads files 

may inadvertently violate access restrictions or pass sensitive system information.  

Code that writes files may modify or damage documents or introduce Trojan horses.  

Analyze the code's interaction with other programs or applications.  For example, 

many CGI scripts send e mail in response to form input by opening up a connection 

with the sendmail program.  Ensure this interaction is performed in a secure manner.  

On Linux/Unix hosts, the code should not run with suid (set user id).  

The code should use explicit path names when invoking external programs.  Relying 

on the PATH environment variable to resolve partial path names is not recommended. 

Web servers (whether or not they employ active content) should be scanned 

periodically for vulnerabilities (see Section 9.4.1).  There are several scanners that 

specifically scan for content generator vulnerabilities (e.g., Whisker and Retina, see 

Appendix E).   

For data entry forms, determine a list of expected characters and filter out unexpected 

characters from input data entered by a user before processing a form.  For example, 

on most forms, expected data falls in these categories: letters a z, A Z, and 0 9.  

Device names such as AUX, COM, LPT, NUL, and PRN should also be filtered from 

the input data.  

Ensure that the dynamically generated pages do not contain dangerous 

metacharacters.  It is possible for a malicious user to place these tags in a database or a 

file.  When a dynamic page is generated using the tampered data, the malicious code 

embedded in the tags may be passed to the client browser.  Then the user's browser 

can be tricked into running a program of the attacker s choice.  This program will 

execute in the browser's security context for communicating with the legitimate Web 

23

 There are a number of reasons for the poor security of many PHP scripts.  The most obviously being that many 

scripts are written without security being a concern.  In addition due to the relative ease of coding PHP scripts many 

novices who have little knowledge of secure programming create (and often freely distribute) poorly written (from a 

security prospective) scripts.  PHP can be very secure as long as an experienced programmer codes it with security as 

a primary consideration.   

47