CGI安全问题

[作者:佚名|来源:赛酷建站|时间:2006-08-20| 收藏投稿 ]【大中小】

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〉 "
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一切看起来都正常，不过…

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

大部分情况下，正确但聪明地编写的表单提交会导致比越界数据更多的问题。忽略无意义的输入很容易，但确定合法的、正确格式的输入会不会导致问题就要困难得多。因为CGI脚本非常灵活，几乎可做计算机能做的任何事情，所以安全方面的一个很小失误往往能被无限制地加以利用——而这正是最危险的地方。

2.7 处理文件名

文件名是提交给CGI脚本的简单数据，但如果不小心的话，却能导致许多麻烦。如果用户输入的名字中包含路径因素，如目录斜杠和双点，尽管期望的是输入一个简单的文件名--例如file.txt--但结果却可能是/file.txt或../../../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 ("〈HTML〉〈TITLE〉Greetings!〈TITLE〉〈BODY〉 ");
print ("Hello,$user_Name! It’s good to see you! ");
print ("〈/BODY〉〈HTML〉 ");

想像一下，如果用户不是仅仅输入一个名字，而是输入了

〈HR〉〈H1〉〈P ALIGN="CENTER"〉John Smith〈/P〉〈H1〉〈HR〉

或想像一下当脚本希望得到用户名时，黑客输入了

〈IMG SRC="/secret/cutekid.gif"〉

，结果是公开了本该保密的信息。允许输入HTML可能很危险。

比输入简单的HTML修改页面或访问画面更危险的是恶意的黑客可能输入一条服务器端的include指令。如果web服务器设置为服从服务器端include，用户就可以输入

〈!--#include file="/secret/project/p1an.txt"--〉

而不是他的名字，以便看到秘密计划的全部文本,或者用户可以输入来获取机器的口令文件。可能最坏的情况是黑客可能输入而不是他的名字。这样上述程序清单中的代码会删掉硬盘上几乎所有内容。

警告

由于经常被恶意地使用，服务器端的include经常被禁止使用以保护站点免受侵害。现在假定这些都没问题。即使关闭了服务器端的include并且不介意用户能看到自己硬盘上的任何图片或者改变页面显示的外观，也仍然有问题--不仅是针对编程者的，而且针对其他用户。

CGI脚本的一个通常用途是留名册(guestbook):访问站点的顾客可能签个名，让别人知道他们已经在那儿了。一般情况下用户简单地输入他的名字，该名字会在访问者清单中出现。但是，如果将The last signee！<FORM><SELECT>作为用户名输入怎么办?<SELECT>标记将导致Web浏览器忽略位于<SELECT>和一个不存在的</SELECT>之间的所有内容，包括以后清单中加入的任何名字。即使有10个人签了名，仅有前3个会显示出来，因为第三个名字包含一个<FORM>和一个<SELECT>标记。因为第三个签名者在他的名字中使用了HTML标记，他后面的任何名字都不会显示出来。

对于用户输入HTML而不是普通的文本的情况有两种解决办法:

1)快速但比较粗糙的办法是不允许小于号(<)和大于号(>)，因为所有HTML标记必须包含在这两个字符中，所以清除它们(或者如果碰到它们就返回一个错误)是一种防止HTML被提交并返回的简单的办法。下面一行Perl代码简单地清除了这两个字符:$user_Input=~s/<>//g;

2)更精细一点的办法是将这两个字符转换成它们的HTML换码--—种特殊的代码，用于表示每个字符而不使用该字符本身。下面的代码通过全部用<替换了小于符号，用>替换了大于符号，从而完成了转换:

$user_Input=~s/</&1t;/g;
$user_Input=~s/>/>/g;

Tags：