上一篇：非安全编程演示之格式化字符串篇 >>

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的程序员可以使用流行的visualbasic，这意味着有经验的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。如果愿意的话，可以自由地编辑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 eq "button_one"){
# button one has been clicked }
else {
# button two has been clicked }

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

　cgi脚本应该能预期这种情形而相应地进行处理。例如，如果出现一些非预期的或"不可能"的情形，可以打印一个错误，如下所述:

if ($form_data eq "button_one") {
#button one seleted }
elsif ($form_data 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);
#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); }
elsif ($input_method eq "post") {
#"post"
local($input_size)=$env;
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"<html><header><title>file</title><header><body>"
echo"here is the file you requested:<pre>\n"
cat $path_info
echo "</pre></body><himl>"

　尽管在用户只单击预定义的链接(即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)在路径中单个点(.)和两个点(..)的序列也有特殊含义。单点意味着对"对于当前目录",而双点意味着"相对于当前目录的父目录"。聪明的黑客可以建立象../../../etc/passwd这样的串逆向三层，然后向下进入/etc/passwd文件。应拒绝任何包含双点序列的内容。

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

　4)基于nt的服务器还支持univesal naming conventions(unc)引用。一个unc文件规格指定机器名和一个共享点，其余部分与指定机器上的指定的共享点有关。unc文件规格总是以两个反斜线开头。应拒绝任何unc路径。

2.6一切看起来都正常，不过…

（）

返回顶部

下一篇：SQL Server补丁版本的检查和安装过程中常见问题 >>