CGI Scripting Perils

The prototypical web server requires very little in the way of user authentication. The server is accessible to the public at large and delivers content to anybody who wants it. This configuration is at least theoretically low in security risk because static web servers deliver unchanging data, provide very limited client-to-server data transfer facilities, and don't enable users to run arbitrary programs locally. Therefore, if a web server has no bugs and if it's properly configured (two very big ifs), a miscreant is unlikely to be able to abuse a web server.

Dynamic content adds an entirely new dimension to this equation, though. CGI scripts enable outsiders to run programs that aren't part of the web server. These programs are often written by individuals who don't have extensive knowledge of how to write secure software. As a result, CGI scripts sometimes contain severe security flaws, which might be exploited by crackers. These problems are exacerbated if you run Apache with a too-high privilege level. Most default installations set the server to run as a low-privilege user, such as apache or nobody. Doing so minimizes the risks associated with CGI scripts, but a poorly written script in conjunction with local security flaws could still enable intruders to do a great deal of harm even with these limited privileges. The same is true if the scripts need to be able to change critical data, such as customer information databases; with such access, a bug in a script or a limited intrusion via Apache could irreparably damage the databases.

Another approach to limiting the potential of scripts to do serious damage is to run them in a chroot jail, as described in Chapter 20. As with using limited-access accounts, though, this approach isn't perfect. Any data that a script must be able to manipulate will be accessible to the server even within the jail. As noted in Chapter

This document was created by an unregistered ChmMagic, please go to to regist* 20, it's possible to break out of a jail, given root privileges.

Overall, CGI scripting is risky. This risk is offset by its flexibility. You may have no choice but to run a web server that can handle CGI scripting. If so, you may want to use physically separate servers for CGI scripts and for static content. Doing so will help you isolate any potential harm from a compromise of the CGI scripting system. This approach may also help you balance the load to your website as a whole. A web server that handles primarily static content doesn't need to be as powerful as one that handles CGI scripts. This is because delivering static content requires little in the way of CPU power, whereas CGI scripts must be run, and therefore consume at least some extra CPU time. Depending on your site's size and traffic level, you may be able to use an older computer to deliver static content and place CGI traffic on a more capable system that's devoted entirely to this task.

Team LIB

1 previous

Team LiB

^ previous

0 0

Post a comment