网站地图 | RSS订阅 | 实用查询
您的位置:网站首页 > 电脑编程 > 网络安全

浅谈CGI的 安全问题

作者:掌柜 来源:未知 日期:2011-7-5 22:05:06 人气: 标签:
导读:计算机领域——尤其在Internet上——尽管大部门Web服务器所编的程序都尽可能保护自己的内容不受侵害,但只要CGI脚本中有一点安全方面的失误--口令文件、私有数据…
计算机领域——尤其在Internet上——尽管大部门Web服务器所编的程序都尽可能保护自己的内容不受侵害,但只要CGI脚本中有一点安全方面的失误--口令文件、私有数据、以及任何东西,就能使入侵者能访问计算机。遵循一些简朴的规则并保持警惕能使自己的CGI脚本免受侵害,从而可以保护自己的权益。

1. 脚本和程序

在开始决定采用何种语言编写CGI脚本时应考虑几个因素,其中之一应是安全性。Shell 脚本,Perl程序和C可执行程序是CGI脚本最常采用的形式,从安全性角度来说每种都备有优缺。尽管没有哪一种是最好的--基于其他方面的考虑,如速度和可重用性--每种都有实用的领域。

Shell脚本一般用于小的、快速的甚至可以用完就不要的CGI程序,因此,编写它们时经常不考虑安全性。这种疏忽可以导致一些缺陷,使得仅对系统具有一般知识的人也能进入系统任意走动。

尽管Shell CGI 程序最轻易写,甚至只需拼凑一下即可,但控制它们却很难题,由于它们一般是通过执行外部的其他程序来完成工作的。这就导致一些可能的隐患,CGI 程序会继续任何它使用的程序的安全题目。

例如,常用UNIX实用程序 awk对于它能处理的数据的数目有一些相称严格限制。假如在CGI脚本中使用awk,那么该程序也就有了同样的限制。Perl比Shell脚本更进一步。Perl用于CGI编程有良多长处,并且相称安全。但Perl能给CGI 作者提供足够的灵活性从而导致对安全性的错误感觉。例如,Perl是解释型的。这意味着它实际在调用时是先编译,然后每次执行一步。这就很轻易使得不准确的用户数据被包括进来作为代码的一部门,从而错误地进行解释,形成程序中止原因。

最后谈谈C。C迅速成为尺度应用开发语言,几乎所有的UNIX和windows NT系统都是用它开发的。从安全性的角度来看C 好像是很不错,但因为它的流行性,它的好几种安全性题目已广为人知,而这些题目也能很轻易地被人利用。

例如,C 对串处理非常差。它不做任何自动的定位或清理而让编程者自己处理所有事情。在处理串时,大部门C 程序员都是简朴地建立一个预定义的空间并但愿它足够大以便处理用户输入的任何内容。

当然,Shell脚本、Perl和C 不是仅有的编写CGI脚本语言。实际上,任何可以按预定义的方式与Web服务器进行交互的计算机语言都可以用于编写CGI程序。在UNIX和Windows NT服务器上,数据是通过环境变量和尺度输入(stdin) 传给脚本的,所以任何能从这两种数据源读取并写入尺度输出(sidout)的语言都能用于创建CGI:awk、FORTRAN、C++、Basic和COBOL,等。windows的程序员可以使用流行的Visual Basic,这意味着有经验的VB程序员不必去学一门新语言。Macintosh使用AppleEvents、和AppleScript与CGI程序进行通讯,所以任何可以读写这两者的语言都可使用。

不外,Shell脚本(无论使用那种Shell)、Perl和C还是最流行为的编写CGI脚本的语言。这并不是说必需使用它们了;只是说大部程序的库——即大部门经由测试的安全的库——都是用这三种语言编写的。假如自己来选择CGI编程语言,最好是鉴戒前人的经验。

2. 谁也不信

几乎所有的CGI 安全题目都来自与用户的交互。接收来自外部数据源的输入之后一个简朴的、可预见的CGI程序溘然向多方向舒展,每个方面都可能有最小的缝隙使得“黑客”可以溜进来。恰是与用户的这种交互——通过表单或文件路径——才给予了CGI 脚本这种能力,但同时也使得它们成了运行在Web服务器上的最潜伏的危险部门。

编写安全的CGI 脚本很大程度上是创造性和妄想的结合。编写者必需有足够的创造性才能想到用户使用的,无论是无意地仍是别的所有的可能隐含导致题目的发送数据的方式。而且必需有点妄想,由于有可能不知道什么时候、什么地方、他们将会逐一加以试验。

2.1 两种导致题目的方式

当用户登录进入Web 站点并开始进行交互访问时,他们能以两种方式惹麻烦。一种是不遵守规则,歪曲或违背页面中建立的每个限制或约束;另一种方式是按要求去做。

大部门CGI 脚本是作为HTML表单的后台运行的,负责处理由用户输入的信息并提供某种定制的输出。由于在这种情况下,大部门CGI 脚本编写时都等待某种特殊格局的数据。它们期望用户的输入能匹配收集并发送信息的表单。不外事情并不老是这样。用户可以有很多种办法绕过这些预定义的格局而给脚本发送一些看起来是随机的数据。CGI 程序必需对此有所预备。

其次,用户可以给CGI 脚本发送所期望的数据类型,按预期的形式在表单中填入每个字段。这种类型的提交可以是想像中的来自某个与站点交互的无意的用户,也可能来自某个恶意的“黑客”,凭借他有关操纵系统和Web 服务器软件的知识并利用常见的编程错误。这些入侵,表面上一切都正常,却是最危险的、最难检测出来。Web 站点安全性依靠干这种入侵的防止。

2.2 不要相信表单数据

在CGI 编程中最常见的安全失误就是相信从表单传到脚本的数据,用户是未知的一大堆人,他们总能找到一些编程职员从来没想到过的发送数据的方法--而且是程序员以为几乎不可能的方法。

脚本必需对这些加以考虑。例如,下面这些情形都是可能的:

1)从一组单单选按钮中选择的结果可能不是表单中提供的选项之一。

2)来自某个文本字段的数据长度可能大于MAXLENGTH字段答应的长度。

3)字段本身的名字可能与表单中指定的不相符。

2.3 不公道数据的来源


因—些无意的或是有意的原因,导致自己的脚本接收到不知道如何去处理的数据,有可能导致非预期的——同时很危险的——行为。

下面的代码实现了一种表单并向某个搜索yahoo!数据库的CGI脚本送垃圾。该脚本设计得很好并且很安全,由于它忽略了不熟悉的输入。



Enter your name,first then last:



也许用户碰劲(或者意识地)将URL编纂为这个CGI脚本。当浏览器向CGI程序提交数据时,要简朴地将输入表单中的数据连到CGI的URL上(用于GET METHODS),就像用户可以很轻易地将Web页面地址输入到他的浏览器一样,用户也可以自己修改发送给这个脚本的数据。

例如,当单击表单上的Submit按钮时,Netscape将一个长串字符放入Location字段,该串由CGI的URL后接一串数据组成,大部门看起来像表单中定义的NAMES和VALUES。假如愿意的话,可以自由地编纂Location字段的内容并按自己的意愿修改数据:增加表单中没有的字段,扩展由MAXLENGTH选项限制的文本数据,或者几乎任何对象。以下显示了某CGI脚本预期从表单中提交的URL。

http://www.altavista.digit.com/cgi-bin?pg=q&what=web&imt=&q=%22An+Entirely+Other%22

用户可以修改统一URL,CGI脚本仍被调用,但现在接收的长短预期的数据。为了保证安全,该脚本应该在编写时就设计为能将这种输入识别为不被要求的数据并加以拒绝。

最后,某个有野心的"黑客"也许会写一个程序连到Web上的服务器并假装是一个Web浏览器。该程序可能做一些任何一个真正的web浏览器从未做过的事,例如给CGI脚本发送成百兆字节的数据。假如CGI脚本不限制从POST METHOD读取数据,那怎么办?它有可能会崩溃,也许答应那个崩溃了系统的人访问系统。

2.4 拒绝分歧要求的表单数据

CGI脚本可以有几种方式拒绝接收提交给它的非预期的输入。编写CGI时应该使用其中一些技巧或所有这些技巧。

首先,CGI 脚本应设置接收多少数据的限制,不仅限制整个提交,也限制提交中的每个NAME/VALUE对。例如,CGI脚本读取POST METHOD,检查CONTENT-LENGTH环境变量的大小来确定某输入是不是公道的预期输入。假如CGI 脚本设计接收的独一数据是某人的姓名,那么假如CONTENT-LENGTH大于100字节,就应该有理由返回一个错误。没有哪个公道的姓有那么长,通过设置限制,就能使脚本不再盲目地读取发送给它的内容。

留意

令人兴奋的是,不必担心去限制通过POST方法提交的数据。GET是自限制的并且不会向脚本发送多于1KB的数据。服务器自动限制放人QUERY-STRING环境变量中的数据的大小,而这恰是GET发送给CGI程序的信息。

当然,"黑客"们可以很轻易地将表单由GET改为PUT从而绕过这种内置的限制。至少,程序应该检查一下数据是否是用预期的方法提交的;最好是能准确且安全地处理两种方法。

下一步,应保证脚本知道在接收到不能识别的数据时该怎么办,例如,假如某表单要求用户选择两个单选按钮之一,脚本就不应该假设由于一个按钮未被选择,另一个就一定被选择了。下面的Perl代码就犯了这样的错误:

if ($form_Data{"radio_choice"} eq "button_one"){
# Button One has been clicked }
else {
# Button Two has been clicked }

这段代码假定由于表单仅提供了两个选项,而第一项未被选中,那么第二项就肯定被选中了。这不一定是真的。尽管前面的例子没有什么害处,但在某些情况下这样的假设可能很危险。

CGI脚本应该能预期这种情形而相应地进行处理。例如,假如泛起一些非预期的或"不可能"的情形,可以打印一个错误,如下所述:

If ($form_Data{"radio_choice"} eq "button_one") {
#Button One seleted }
elsif ($form_Data{"radio_choice} eq "button_two") {
#Button Two Selected }
else {
#Error }

通过加入第二个if语句--显式检查"radio_choice"实际上是"button_two"--这样脚本更安全了;它不再做假设了。

当然,错误不一定是期望脚本在这些情形下天生的。有些脚本过于小心,验证每个字段,即使是最稍微的非预期数据都天生错误信息,这样往往很扫用户的兴。让CGI 脚本识别非预期数据然后扔掉它,并且自动选择一个缺省值也可以。

另一方面,脚本还可匡助用户纠正错误而不是简朴地发一条错误动静或设置一个缺省值。假如表单要求用户输入秘要文字,脚本应能在进行比较之前自动跳过输入中的空缺字符。下面等于一个完成此功能的Perl程序片断。

$user_input =' s/s//;
#Remove white space by replacing it with an empty string
if ($user_input eq $secret_Word) {
#Match! }

最后,可以更进一步,让CGI脚本能处理尽可能多的不同的输入表单。尽管不可能预期到可能发送给CGI程序的所有内容,但对某个特定方面一般常常有几种常用的方式,因而可以逐个检查。

例如,仅仅由于所写的表单使用POST方法向CGI脚本提交数据,并不意味着数据必需按那种方法进来。应该检查REQUEET_METHOD环境变量来确定是使用了GET仍是POST方法并相应地读取数据,而不是假定数据都是来自预期的尺度输入(stdin)。一个真正编写成功的CGI脚本能接收不管使用什么方法提交的数据并在处理过程中很安全。以下程序清单等于用Perl编写的一个例子。

程序清单 CGI_READ.PL 一个布满活力的读取格局输入的程序

#Takes the maximum length allowed as a parameter
#Returns 1 and the raw form data,or "0" and the error text
sub cgi_Read
{
local($input_Max)=1024 unless $input_Max=$_[0];
local($input_Method)=$ENV{'REOUEST_METHOO');
#Check for each possible REQUEST_METHODS
if ($input_Method eq "GET") {
#"GET"
local($input_Size)=length($ENV{'QUERY_STRING'});
#Check the size of the input
if($input_Size>$input_Max) {
return(0,"input too big"); }
#Read the input from QUERY_STRING
return(1,$ENV{'QUERY_TRING'}); }
elsif ($input_Method eq "POST") {
#"POST"
local($input_Size)=$ENV{'CONTENT_LENGTH'};
local($input_Data);
#Check the size of the input
if ($input_Size>$input_Max) {
return(0,"Input too big"); }
#Read the input from stdin
unless (read(STDIN,$input_Data,$input_Size)) {
return(0,"Could not read STDIN"); }
return(1,$Input_Data);
}
#Unrecognized METHOD
return (0,"METHOD not GET POST");
}

总而言之,脚本应该分歧错误接收的表单数据进行假设,应尽可能预计意料之外的情形并准确地处理不准确的或错误的输入数据。在使用数据之前应按尽可能多的方式测试它;拒毫不公道的输入并打印一条错误动静;假如某项犯错或漏了应自动选择一个缺省值;甚至可以试图对输入进行编码以成为程序的公道的输入。选择哪种方式依靠于自己想花费多少时间和精力,不外记住永远也不要盲目接收传给CGI脚来的所有信息。

2.5不要相信路径数据

用户能修改的另一类型数据是PATH_INTO的服务器环境变量。该变量由CGI URL中紧跟在脚本文件名之后的任何路径信息填充的。例如,假如foobar.sh是一个CGl shell脚本,那么当foobar.sh运行时,URL http://www.server.com/cgi-bin/foobar.sh/extra/path/info将导致/extra/path/info被放进PATH_INFO环境变量中。

假如使用这个PATH_INFO环境变量,就必需小心地完全验证它的内容。就像表单数据能以很多种方式被修改一样,PATH_INFO也可以修改。盲目地根据PATH_INFO的中指定的路径文件进行操纵的CGI脚本可能会让恶意的用户对服务器造成伤害。

例如,假如某个CGI脚来设计用于简朴地打印出PATH_INFO中引用的文件,那么编纂该CGI URL的用户就可以读取机器上的几乎所有文件,如下所示:

#!/bin/sh
#Send the header
echo "Conext-type:text/html"
echo""

#Wrap the file in some HTML
#!/bin/sh
echo"
"
echo"Here is the file you requested:
n"  

cat $PATH_INFO

echo "
"

尽管在用户只单击预定义的链接(即http://www.server.com/cgi-bin/foobar.sh/public/faq.txt)时,该脚本正常工作,但是一个更有创造性的(或恶意的)用户可能会利用它接收服务器上的任何文件。假如他想进入http://www.server.com/cgi-bin/foobar.sh/etc/passwd,前面的脚本会很兴奋地返回机器的口令文件——这可是不但愿发生的事。

另一种安全得多的方式是在可能时使用PATH_TRANSLATED环境变量。不是所有的服务器都支持该变量,所以脚本不能依靠于它。不外假如有的话,它能提供完全润饰的路径名,而不是像PATH_INFO提供的相对URL。

不外在某种情形下,假如在CGI脚本中使用PATH_TRANSLATED的话,则可以访问通过浏览器不能访问到的文件。应该知道这点及它的应用。

在大部门UNIX服务器上,htaccess文件可以位于文档树的每个子目录,负责控制谁能够访问该目录中的特殊文件。例如它可以用于限制一组Web页面只给公司雇员看。

固然服务器知道如何解释.htaccess,从而知道如何限制谁能仍是不能看这些页面,CGI脚本却不知道。使用PATH_TRANSLATED访问文件树中任意文件的程序有可能碰劲笼盖了服务器提供的保护。

不管使用PATH_INFO仍是PATH_TRANSLATED,另一个重要的步骤是验证路径以确保它或者是一个真正的相对路径或者是脚本认可的几个正确的、预知的路径之一。对于预定的路径,脚本将简朴地将提供的数据与认可可以使用的文件的内部清单进行比较,这就是说在增加文件或修改路径时必需重新编译脚本,但安全性却有了保障。只允计用户选择几个预定义的文件而不答应用户指定实际的路径和文件名。

下面是处理访问者提供的路径时应遵循的一些规则。

1)相对路径不以斜线开头。斜线意味着"相对于根"或绝对路径。假如有的话,CGI脚本也是很少需要访问Web根之外的数据。这样它们使用的路径就是相对于Web根目录,而不是绝对路径。应拒绝任何以斜线开始的内容。

2)在路径中单个点(.)和两个点(..)的序列也有特殊含义。单点意味着对"对于当前目录",而双点意味着"相对于当前目录的父目录"。智慧的黑客可以建立象http://www.zhujiangroad.com/http://www.zhujiangroad.com/http://www.zhujiangroad.com/etc/passwd这样的串逆向三层,然后向下进入/etc/passwd文件。应拒绝任何包含双点序列的内容。

3)基于NT服务器使用驱动器字母的概念来引用磁盘卷。包含对驱动器的引用的路径都以一个字母加上一个冒号开头。应拒绝任何以冒号为第二个字符的内容。

4)基于NT的服务器还支持Univesal Naming Conventions(UNC)引用。一个UNC文件规格指定机器名和一个共享点,其余部门与指定机器上的指定的共享点有关。UNC文件规格老是以两个反斜线开头。应拒绝任何UNC路径。

2.6一切看起来都正常,不外…

现在已经知道了用户能给CGI脚本提供非预期的数据的几种方式以及如何对付它们了,余下的更大题目是如何验证用户提交的正当数据。

大部门情况下,准确但智慧地编写的表单提交会导致比越界数据更多的题目。忽略无意义的输入很轻易,但确定正当的、准确格局的输入会不会导致题目就要难题得多。由于CGI脚本非常灵活,几乎可做计算性能做的任何事情,所以安全方面的一个很小失误往往能被无穷制地加以利用——而这恰是最危险的地方。

2.7 处理文件名

文件名是提交给CGI脚本的简朴数据,但假如不小心的话,却能导致很多麻烦。假如用户输入的名字中包含路径因素,如目录斜杠和双点,尽管期望的是输入一个简朴的文件名--例如file.txt--但结果却可能是/file.txt或http://www.zhujiangroad.com/http://www.zhujiangroad.com/http://www.zhujiangroad.com/file.txt。根据Web服务器的安装以及对提交的文件名做什么操纵,系统中的所有文件就有可能都暴露给了一个智慧的黑客。

进一步,假如用户输入了一个已有文件的名字或者一个对系统的运行很重要的文件名,怎么办?对假如输入的名字是/etc/passwd或C:WINNTSYSTEM32KRNL32.DLL怎么办?根据在CGI脚本中对这些文件进行什么操纵,它们有可能被发送给用户或者被垃圾笼盖了。在Windows 95和Windows NT下,假如不检查反斜杠字符(),可能会答应Web 浏览器通过UNC文件名访问甚至不在该Web机器上的文件。

假如用户在文件名中输入了不正当的字符怎么办?在UNIX下,任何以句点(.)开头的文件名都是不可见的。在Windows下斜杠(/)和反斜杠()都是目录分隔符。很可能不小心写了一个Perl程序,当文件名以管(pipe)(|)开头时,尽管自己认为仅仅是打开了一个文件,实际上却是执行了一个外部程序。假如用户知道怎么办的话,甚至可以把控制字符(例如Escape键或Return键)作为文件名的一部门送给脚本。

更坏的情况是,在shell脚本中,分号用于结束一条命令并开始另一条命令。假如脚本设计目的是cat用户输入的文件,用户可能输入file.txt;rm-rf/作为文件名,导致返回fi1e.txt,然后清除整个硬盘而不经任何确认。

2.8 输入公道,输出却不公道

为了避免所有这些题目,封闭由它们打开的所有安全缝隙,检查用户输入的每个文件名。必需确保输入恰是程序预期的输入。

这样做的最好办法是将输入的文件名的每个字符与可接收字符的清单进行比较,假如不匹配就返回一个错误。这比维持一个所有正当字符的清单并比较它们要安全得多——要想让什么字符溜掉太轻易了。

以下程序清单是用Perl如何完成这种比较的例子。它答应任何字符字母(大写或小写调)、任何数字、下划线和句点。它还进行检查以确保文件名不以句点开头。这样,该段代码就不答应可以改变目录的斜杠,不答应可以将多条命令放在一行的分号,或者破坏Perl的Open()调用的Pipes了。

程序清单 保证所有字符都是正当的

if (($file_Name =' /[^a-zA-Z_.]/) || ($file_Name =' /^./)) {
#File name contains an illegal characgter or starts with a period
}

警告

尽管上述程序清单中的代码清除了大部门不正当的文件名,但操纵系可能还有一些限制,而该代码没有笼盖到。例如,文件名可以用数字开头吗?或者以下划线开头?假如文件中包含多个句点或者句点后多于三个字符怎么办?整个文件名足够短得能知足文件系统的限制吗?

必需不断向自己提出这种题目。在写CGI脚本时最危险的事是以为用户会遵守指令。实在用户是不会的。保证用户不出错误是编程者自己的事。

2.9 处理HTML

另外一种看起来无害的但却能导致很大麻烦的输入是在哀求用户输入文本信息时得到的HTML。以下的程序清单是一个Perl程序片断;它向任何在$user_Name变量中输入了一个名字的人,例如John Smith,发出问候信息。

程序清单 发出定制的问候脚本

print ("
"
echo "<YOU crack open cookie and the fortune reads:
"  

fortune

echo "
"

该脚本看起来可一点没有害处。它不接收用户输入,所以用户不能籍此搞什么把戏。由于它仅由Web服务器运行,所以脚本本身的权限设置可以非常严格,可以防止任何有企图的本地用户修改它。假如对该脚本所在的目录也设置了准确的权限的话,看起来就没什么地方可以出题目了,是不是?

当然还有题目。记住得要有点偏激。

上述程序清单调用了外部程序,在本例中是echo和fortune。由于这些脚本没有用显式路径指明它们在硬盘上的位置,该shell即使用PATH环境变量来找到它们,从变量中的每一项查找要执行的程序。这可能很危险。例如,假如fortune程序安装在/usr/games中,但PATH中在它之前列出了/TMP,那么任何碰劲命名为"fortune"并位于临时目录的程序都会被执行,而不是真正的fortune。

该程序可以做它的创建者想做的任何事情,可以删除文件,也可以登记有关哀求信息并将数据传给真正的fortune——使用户和编程者谁也不智慧。在CGI脚本中运行外部程序时一定要指定显式的路径。PATH环境变量有很大作用,但它与其他变量一样也能被非法使用。

4 使用他人CGI脚本时的留意事项

关于CGI,可以从良多地方获得信息——从Internet上,从学校藏书楼中,从像本书这样的书中,UseNet组中以及朋友和同事中。从这些地方不仅可以获得信息,还可以得到实际的程序和库。有些程序和库假如已经有人做过了为什么自己还要从头再做一遍呢?但就像不能盲目服从别人的意见一样,关于如何理财,如何驾车或者糊口中的别的方面,同样,也不能在自己的服务器上盲目地运行另从的代码。从Net上得到的脚本也可能真恰是很好的脚本。但也许并不是。花些时间考察一下脚本的来源以及获取它的站点的可靠性是值得的。

4.1 追根求源

某些Web拥有者。假如不能看到并研究源代码的话,他们甚至都不会运行一个公共的、免费的或贸易性的脚本。这可能有点偏激。假如某个声誉很好的公司销售一个文档具体且广为使用的脚本,该脚本应该比自己写的脚本更安全一些。原因有二。首先,专业人才知道并能避免一些常见的安全漏洞;其次,公司是为了嫌钱而做生意,假如他们以次充好或销售那些恶意的产品就不能再做生意赚钱了。

从另一方面来看,假如UseNet组中看到一个编译好的可执行文件出自一个从没听说过的人,没有什么文档可以看,也没有该程序的用户可以交流交流,那么在将它放入自己的服务器之前一定要仔细考虑。也有可能这是来自一个像自己一样的另一个CGI编程者的完全正当的贡献,目的是想让全世界共享他的编程成果。但它也可能来自某个恶意的,具有反常幽默感的,只想看到自己能使多少人清盘的人。

在评价公共的免费软件或贸易性软件时,应考虑下面这些方面:

该脚本来自一个声誉好的站点吗?该站点存在很长一段时间了吗?它维护得好吗?Web拥有者在发布文件前进行检查吗?

有没有足够的文档说明该程序如何工作以及用户如何使用等信息?

有多少人已经下载了该脚本?该站点愿意提供顾客名单吗?(仅在有疑问时才去询问;Web拥有者不会整天去回答这类题目。)

有人在UseNet上讨论该脚本吗?假如有,他们说好仍是不好?假如没人提到该脚本可以进一步哀求别人的见解。一般总会有人响应的。

提示

在评价脚本时检查下面这些useNet组: comp.security.announce,comp.securiy.unix,以及comp.infosystem.www.authority.cgi。另外还可以访问位于ftp.cert.org的Computer

Emergency Response Team,以了解安全题目的历史及有关工作以及安全保护的软件。

5)该脚本的作者有没有一些别的好名声的脚本?

6)源代码能得到吗?免费的或有价的都行。

7)该程序是不是过份宣传它的能力?假如是,这可能是一个编程新手。

8)该站点自己运行了该脚本吗?假如没有,为什么?能找到别的站点运行该脚本吗?过分偏激以及时间限制

尽管游览取自Web的所有代码是个好主意,但要花费良多时间,特别是当代码比较复杂时更是如斯。

例如,NCSA HTTPd就太大了,一般用户不可能一行行去读,但是从它的主站点http://www.ncsa.uiuc.edu下载它却能保证极好的完整性,知足任何用户的需要。实际上,任何从NCSA下载的东西都是有保障的。

实际上,Web上的很多闻名的站点已经为用户做了大部门的几乎偏激的代码检查工作。从它闪中下载代码是可能利用的另一层另一层保护。这些站点包括:

ftp://ftp.ncsa.uiuc.edu/Web/httpd/Unix/ncsa_httpd/cgi(the NCSA Archive)
http://www.novia.net/'geewhiz(Virtual Webwerx Division Zero-CGI Land)
http://www.lpage.com/cgi(the World-Famous Guestbook Server)
http://sweetbay.will.uiuc.edu/cgi++(cgi++)
http://www.aee.com/wdw(the Web Developers Warehouse)

4.2 留意礼貌

最后,假如确实但愿从Web上下载一些CGI代码,或者完整地使用它,或者用作自己编写的更大程序的一部门,还应了解一些事情。

代码是兔费的并不意味着可以自由地用它作自己想做的任何事情。通常程序和库是禁止拷贝的,假如原始作者没有抛却这个权力,他即能限制如何使用该程序。例如,作者可能禁止拆散该脚本,及禁止用道别的脚本的一部门。

一跟来说,在使用别人的代码之前(即使已经确定它是安全的),最好与作者进行联系取得许可。至少这样做比较有礼貌。而大部门情况下,作者会很兴奋他的代码能被别人利用。当然,假如在自己程序某个片断处注明原始作者将是很礼貌的。
本文网址:
共有:条评论信息评论信息
发表评论
姓 名:
验证码: