如果要加强Apache服务器的安全性，就应该检查CGI（公共网关接口）的使用。一个应用程序中的漏洞通常在用户接触数据库时的某个地方暴露出来，而这个地方正是CGI.它是Web服务器和外部程序之间的桥梁，用来告知这些程序该如何执行以满足浏览器的需求。CGI控制着两个方向的数据格式。它是一个协议，而不是一种语言，可以用很多方法来实现。
寻找安全漏洞
CGI脚本的一个大问题是服务器的默认设置很容易被利用。下面一些是最危险的：
1.以Web服务器用户运行。默认地，所有的 CGI脚本以相同的用户身份运行，即Web服务器本身。虽然这看起来像一个安全性的大敌，却是有意义的。CGI脚本控制着拥护和服务器之间的接口，因此这些脚本需要不同的文件访问权限。给所有的脚本以Web服务器本身的权限，然后再由管理员逐个程序来限制，这样的默认设置简单明了。问题是，管理员永远也完成不了这些限制工作。
2.脚本目录很容易被找到。导致脚本易于被访问和操纵。服务器上默认存放CGI脚本的目录是cgi-bin.如果黑客知道了脚本的位置，就等于拥有了打开宝藏库的钥匙。
3.扩展名众所周知。默认的，CGI脚本扩展名为。cgi.Apache服务器将所有扩展名为。cgi的文件都当作CGI来处理。如果整个服务器都这样通过扩展名来识别脚本而且不将脚本限制在某个目录中的话，黑客就可以运行未经授权的CGI脚本而不需要经过管理员的允许。
紧密封装起来
CGI脚本嵌入在Web应用程序中，带着用户直接进入服务器内部，在这里脚本拥有权限，能够访问服务器资源，恶意的用户会滥用这些权限。但是你可以在此增加一层保护层，办法是将CGI脚本封装隔离起来，从而使CGI脚本、应用程序以及用户无法利用服务器的设置缺陷。封装器可以拥有访问CGI脚本所必须的权限和资源，这样黑客最多只能拥有封装器的权限和资源，而不是脚本本身。
SuEXEC可以解决大多数问题
Switch User for Exec（suEXEC）是一个用来对付很多CGI危险的管理工具。它允许服务器管理员以用户而不是Web服务器用户身份运行CGI脚本。一个用户的程序将以其ID运行。使用CGI脚本的应用程序就能被限制在它们特定的用户环境下。
这就解决了权限问题。你已经有效地创建了一个封装，将用户与系统root权限隔离起来。另外，每次有脚本运行时，suEXEC包装器都将检查其安全性，动态验证程序调用、用户、文件位置和权限，以及所有由管理员定义的东西。
启用suEXEC
从1.2版开始，suEXEC成为Apache的一部分。1.3.x版本以后，它的启用成为Apache配置的一部分内容，键入以下命令：
enable-suexec
指定名字和路径（区别于用户路径）也很简单：
suexec-
caller=USERNAME
suexec-docroot=DIR （default is htdocs）
你可以设置其他参数来加强用户ID的安全性。这包括设置合法的文件路径、用户ID限制以及合法的用户根目录。更多请参考文档说明。
其它CGI包装器
一个名为FastCGI的基于库的包装器也是一种选择。它更像一个对付黑客面向程序员的工具而不是一个管理员工具。FastCGI扩展了CGI规范，提供了包含安全I/O方法的程序插件。这就允许开发者可以将使用其他方法来加强CGI脚本安全性，例如调整内存段的使用以防其被误用。
CGIWrap在Web服务器和可执行程序之间建立了一个附加层，它与suEXEC在很多方面相似，例如以非Web服务器用户身份运行CGI脚本。它也在每个脚本运行时进行安全性检查。
使用别名
可以通过为脚本目录起晦涩难懂的名字来阻止恶意用户查询CGI脚本。除了cgi-bin目录，服务器不会执行其它目录下的CGI脚本。但是使用别名，就可以隐藏它。在配置文件httpd.conf中这样做：
ScriptAlias？ /cgi-bin/？ "/alternate_directory/cgi-bin/"
这就使得服务器将这个替换目录中的文件作为CGI脚本对待，而正常情况下服务器只认cgi-bin目录下的文件。当然要确保限制用户访问这个目录，否则用户能够通过root权限将自己的CGI脚本放进这个目录，而服务器还会允许其执行。
名字包含什么意思
另一个CGI默认设置是服务器被动地假定任何CGI脚本（例如，扩展名为。cgi的文件）在所有Web服务器可以访问的目录下都是可以使用的。（这种情况只在已经启用了用这种方式鉴别CGI脚本的处理器才会出现，设置于httpd.conf.）
使CGI在特定目录执行比在整个服务器中都可以执行要容易。只需为每个可以执行脚本的目录的Options添加ExecCGI就行。这样，就为特定用户和程序限制了CGI脚本的I/O和资源分配。记住这种功能是一把双刃剑，粗心大意的使用会给黑客入侵提供有效的途径，如同正确使用可以阻止他们一样。
