cgi教学: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脚本送垃圾。该脚本设计得很好并且很安全，因为它忽略了不认识的输入。
<form method="post" action="http://search.yahoo.com/bin/search">
enter your name，first then last:
<input type="text" name="first">
<input type="text" name="last">
</form
也许用户碰巧(或者意识地)将url编辑为这个cgi脚本。当浏览器向cgi程序提交数据时，要简单地将输入表单中的数据连到cgi的url上(用于get methods)，就像用户可以很容易地将web页面地址输入到他的浏览器一样，用户也可以自己修改发送给这个脚本的数据。
例如，当单击表单上的submit按钮时，netscape将一个长串字符放入location字段，该串由cgi的url后接一串数据组成，大部分看起来像表单中定义的names和values。如果愿意的话，可
-
相关文章
2秒记住本站域名
玩过泡泡龙吗？Readygo?Go! 再加上.Com.Cn的后缀，那就是大名小顶的ReadyGo.com.cn