Section 7.6 Web Server Policy

   


7.6 Web Server Policy

graphics/fivedangerlevel.gif

Web server policy should address both security and legal issues. The security issues addressed should be designed to protect the server from attack (and to have a plan of action if it is attacked).

Frequently, a literary or artistic type of person will be designing the content of Web pages but might not have the security knowledge that you do. The strictest policy would be to have all installs and changes done by the SysAdmin or, possibly, by a Webmistress who is highly experienced to dominate the security problems.

This might be too strict. Perhaps you should have those who install nonactive Web pages and images be required to use an account that has an umask of 022. It would be different from the account that may add or alter CGI scripts and programs, the Web server (Apache) configuration files, and other more security-sensitive files. Under no circumstances should non-SysAdmins (other than knowledgeable Webmasters) be allowed to add or change CGI scripts and programs, configuration files, etc.

All CGI programs and scripts, Apache modules, etc., should come only from trusted sources and still should be carefully scanned and even tested to verify no security bugs. Consider something as simple as a CGI program that is called from an HTML form to accept text comments from a browser. It might fork off Mail to send data to a dedicated e-mail address, but easily could have bugs that allow even a novice cracker to make herself root, merely by throwing a semicolon in the Subject text, followed by any root command she desires and another semicolon.

If the CGI script is not extremely careful, it might be doing something like the following. In this C example, the program is building a shell command from the subject that the browser has supplied, presumably to generate e-mail to the Webmistress.

 
 char    *subject; char    buf[200]; FILE    *fp; sprintf(buf, "Mail -s '%s' webmistress@turkey.com", subject); fp = popen(buf, "w"); 

The grave security hole is that the user's input is not checked for validity. If the user supplies a subject of

 
 ' x@y.com;cp /bin/sh /tmp/.sh;chmod 4755 /tmp/.sh;Mail -s 'cool 

the sprintf() would generate the following shell command (ignore the \ and the newline following it):

 
 Mail -s '' x@y.com;cp /bin/sh /tmp/.sh;chmod 4755 /tmp/.sh;\ Mail -s 'cool' webmistress@turkey.com 

In this case, the cracker just made a set-UID shell for himself. If this command gets executed by root, he could add a password entry for himself or manipulate other configuration files.

Even if the effective user is not root, he could manipulate any file that the user running this program can write to by inserting the appropriate commands.

Depending on your agency or company policy for public relations and contracts, some or all proposed Web content should be required to be approved by the legal eagles or public relations types.


   
Top


Real World Linux Security Prentice Hall Ptr Open Source Technology Series
Real World Linux Security Prentice Hall Ptr Open Source Technology Series
ISBN: N/A
EAN: N/A
Year: 2002
Pages: 260

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net