|
CGI教学:CGI安全问题(六)
2007-07-13 08:21
2.10 处理外部进程
最后,CGI脚本如何与带有外部过程的用户输入打交道是应该警惕的另一区域。因为执行一个位于自己的CGI脚本之外的程序意味着无法控制它做什么,必须尽最大努力在执行开始前验证发送给它的输入。
例如,shell脚本经常错误地将一个命令行程序和表单输入合在一起执行。如果用户输入符合要求,一切都挺正常,但是有可能会加入其它命令并非法执行。
下面即是一个产生了这种错误的脚本的例子:
FINGER_OUTPUT='finger$USER_INPUT' echo $FINGER_OUTPUT
如果用户很礼貌地给finger输入了某人的e-mail地址,一切都会正常工作,但是如果他输入了一个e-mail地址,后面再跟一个分号和另一条命令,那么该命令也会被执行,如果用户输入了webmaster@www.server.com;rm-rf/,那麻烦可就大了。
即使没有什么隐藏的命令被加入用户数据,无意的输入错误也可能带来麻烦。例如,下面的代码行会产生一个意料之外的结果——列出目录中的所有文件——如果用户输入是一个星号的话。
echo "Your input:"$USER_INPUT
当通过shell发送用户数据时,就象前面的代码片段所做的那样,最好检查一下shell的meta-character(元字符)——这些可能会导致意外的行为。
这些字符包括分号(允许一行中有多条命令),星号和问号(完成文件匹配),感叹号(在csh下指运行的作业),单引号(执行一条包含其中的命令)等等。就像过滤文件名一样,维护一个允许的字符清单一般要比试图找出每个不允许的字符容易一些。下面的Perl代码片段验证一个e-mail地址:
if ($email_Address ~= /[^a-zA-z0-9_\-\+\@\.]) { #lllegal character! } else { system("finger $email_Address"); }
如果决定在输入中允许shell元字符,也有办法让它们安全一些。尽管可以简单地给未验证的用户输入加上引号以免shell按特殊字符进行操作,但这实际上不起什么作用。请看下的语句:
echo"Finger information:<HR><PRE>" finger"$USER_INPUT echo"</PRE>
尽管$USER_INPUT上的引号可以使shell不再解释一个分号,从而不允许黑客简单地插进来一条命令,但该脚本仍有许多安全方面的漏洞。例如,输入可能是'rm-rf/',其中单引号可以导致甚至在finger不知道的情况下执行黑客的命令。
一种处理特殊字符的较好的办法是对它们进行换码,这样脚本只是取它们的值而不解释它们。通过对用户输入进行换码,所有的shell元字符都被忽略并作为增加的数据传给程序。下面的Perl代码即对非字母数字字符完成这种处理。
$user_Input=~s/([^w])/\\\1/g;
现在,如果用户输入加在某条命令之后,每个字符——即便是特殊字符——都会由shell传送给finger。
不过请记住,验证用户输入——不相信发送给自己的任何信息——会使自己的代码更易读并且执行起来更安全。最好不是在已经执行了命令之后再去对付黑客,而应在门口就对数据进行一次性的检查。
--------------------------------------------
处理内部函数
对于解释型语言,例如Shell和Perl,如果用户输入的数据不正确的话,有可能导致程序生成本来没有的错误。如果用户数据被解释为一部分执行代码,用户输入的任何内容都必须符合语言的规则,否则就会出错。
例如,下面的Perl代码片段也许会正常工作也许会产生错误,这取决于用户输入的是什么:
if ($search_Text =~ /$user_Pattern/) { #Match! }
如果$user_Pattern是一个正确的表达式,一切都会正常,但是如果$user_Pattern不合法;Perl就会失败,导致CGI程序失败——这可能是一种不安全的方式。为了避免这种情况,在Perl中至少应有eval()操作符,它计算表达式的值并与执行它无关,返回一个码值表示表达式是有效的还是无效的。下面的代码即是前面代码的改进版。 if (eval{$search_Text =~ /$user_Pattern
|