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=qwhat=webimt=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 _ c