因—些无意的或是有意的原因,导致自己的脚本接收到不知道如何去处理的数据,有可能导致非预期的——同时很危险的——行为。
下面的代码实现了一种表单并向某个搜索yahoo!数据库的CGI脚本送垃圾。该脚本设计得很好并且很安全,因为它忽略了不认识的输入。
<FORM METHOD="OST" 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{"radio_choice"} eq "button_one"){
# Button One has been clicked }
else {
# Button Two has been clicked }
这段代码假定因为表单仅提供了两个选项,而第一项未被选中,那么第二项就肯定被选中了。这不一定是真的。尽管前面的例子没有什么害处,但在某些情况下这样的假设可能很危险。
CGI脚本应该能预期这种情形而相应地进行处理。例如,如果出现一些非预期的或"不可能"的情形,可以打印一个错误,如下所述:
If ($form_Data{"radio_choice"} eq "button_one") {
#Button One seleted }
elsif ($form_Data{"radio_choice} 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{'QUERY_STRING'});
#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{'QUERY_TRING'}); }
elsif ($input_Method eq "OST") {
#"OST"
local($input_Size)=$ENV{'CONTENT_LENGTH'};
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,另一个重要的步骤是验证路径以确保它或者是一个真正的相对路径或者是脚本认可的几个准确的、预知的路径之一。对于预定的路径,脚本将简单地将提供的数据与认可可以使用的文件的内部清单进行比较,这就是说在增加文件或修改路径时必须重新编译脚本,但安全性却有了保障。只允计用户选择几个预定义的文件而不允许用户指定实际的路径和文件名。