CGI 安全问题

日期：2007年10月29日作者：查看:[大字体中字体小字体]

在计算机领域——尤其在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的程序员可以使用流行的VisualBasic，这意味着有经验的VB程序员不必去学一门新语言。Macintosh使用AppleEvents、和AppleScript与CGI程序进行通信，所以任何可以读写这两者的语言都可使用。

　不过，Shell脚本(不管使用那种Shell)、Perl和C仍是最流行为的编写CGI脚本的语言。这并不是说必须
使用它们了；只是说大部程序的库——即大部分经过测试的安全的库——都是用这三种语言编写的。如果
自己来选择CGI编程语言，最好是借鉴前人的经验。

2. 谁也不信

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

　编写安全的CGI 脚本很大程度上是创造性和妄想的结合。编写者必须有足够的创造性才能想到用户使用