漠漠孤云尽成雨---浅谈CGI脚本安全

　　很多朋友告诉我一定要去不断总结自己学的东西，并且不要吝啬拿出来与人分享，这样才有一个很好的沉淀和交流，还有彼此的促进。于是自己把自己一部分学习笔记整理了一下。还有一些自己平时总结的一些学习经验，希望对大家有所帮助。
　　
　　CGI脚本是在网络服务器上解释执行的，然后将执行的结果返回给客户端（就是我们的浏览器）。因为perl的强大功能、他的灵活性和对所有流行的操作系统的支持，当然还有它的“价格”（纯免费）。使其受到了很多CGI编程者的青睐。我们知道任何语言本身是无安全性可言的，安全只是存在于使用他的人的身上。所以如果在编写脚本时，没有安全的意识，那么编写出的代码也就没有安全的"功能"了。
　　
　　一、注意对变量的处理
　　1、用户的输入是不可信任的，当谈到安全编程的时候，比尔盖茨先生对他的员工说了一句非常经典的话：All input is invalid.（所有的用户输入都是有害的，具体是不是他第一个说的，有待考察）
　　一切用户输入的地方都是我们应当注意的地方。大家知道美国最著名的电子商务网站e***.com吧，他在1999年就被黑客用以下的方法入侵了。我们的新浪网站也被用同一种方法攻了进去，并且还被人截了图。。。。
　　来看一段代码吧：
　　-----------Code Start------------
　　#unsafecodz.cgi
　　01 $filepath="f://myhome//bbs//"
　　......
　　......
　　13 $filename=$query -> param( page );
　　14 if ($filename eq "")
　　15 { $filename="error.html";
　　16 die("对不起，文件名不能为空！");
　　17 }
　　18 else{
　　19 $filename="$filepath/".$filename;
　　20 open(FILE,$filename);
　　21 while()
　　22 {
　　23 print $_;
　　24 }
　　25 close(FILE)
　　......
　　-----------Code Ends-------------
　　
　　这段代码基本上没有作太多改动，因为我演示是在自己的机子上，所以把路径改了一下，我们在这里回放一下曾经的过程。
　　
　　这段代码是网站用来浏览的其他网页的，如：http://127.0.0.1/myhome/bbs/unsafecodz.cgi?page=something.html，就会浏览something.html这个文件，这里的$filename用param提取page中用户输入的内容，$filename其实是用户间接输入的内容，而代码对$filename并没有做严格的审查只是检查是否为空，如果恶意用户直接在浏览器中指定其他文件，如cgi,asp或者任何文件，则返回的是文件的源代码，如：http://127.0.0.1/myhome/bbs/unsafecodz.cgi?page=unsafecodz.cgi。
　　看到unsafecodz.cgi的源代码了，通过简单的浏览其他的页面，我们可以基本上可以得到所有文件的源代码。我们也可以通过"../"来切换到其他的目录下。
　　这还不是最糟糕的，如果你的系统是Linux或者UNIX，那么更过分的在这里呢！http://127.0.0.1/myhome/bbs/cgi-bin/unsafecodz.cgi?page=/../../../../../../ect/passwd。结果显而易见，可以看到了主机的用户名和密码文档。
　　这也不是最遭的，如果利用open函数加管道符执行任意命令的后果会怎么样？利用open函数执行命令的技术很老了，我就不废笔墨了。
　　后来有人对代码进行加固，将第19行改成 $filename="$filepath/".$filename.".html" 他限定后面4位为html,但是这样的加固似乎起不到什么作用，因为它忽略了NULL字符。提交如下请求依然可以绕过他的限定:
　　/myhome/bbs/unsafecodz.cgi?page=unsafecodz.cgi%00.html
　　还是这个问题，还有人这么加固代码，它在将19行改了之后，又将第14行改成：
　　if (($filename eq "") || (-e $filename))
　　他在这里检查文件是否存在，如果不存在就不去进行后面的操作，我们这么依然提交：
　　/myhome/bbs/unsafecodz.cgi?page=unsafecodz.cgi%00.html
　　你会发现我们依然可以成功。
　　他还是忽略了什么，他忽略了什么呢？他忽略了null字符是可以绕开-e的检查，也就是说(-e $filename)将会认为文件是存在的，因为%00后面的东西在-e中会被忽略。
　　
　　ok,这里我们停一下，我们应该能注意到刚才是什么改变了程序本来的流程。就是那个null字符（\0），想想还有什么我们可以用来改成程序的流程呢？\t,\r,\x0B,\n,空格。这些字符都很有用，大家记住它并要学会如何自由运用这些东西。大家是否还记得前不久的dvbbs论坛漏洞，就是由于上传中的null字符所引起的。很多时候你会发现技术突破不过就是你的技术积累沉淀后的爆发。
　　
　　##关键词：用户输入的变量
　　##检查：是否做过有效过滤
　　
　　2、隐式输入的危害
　　用户的输入分为两种，显示输入和隐式输入。上面的例子没有注意到用户的输入导致问题的出现。因为那是用户直接输入的，算是显示输入吧。现在很多程序员都会下意识的去保护自己程序的安全性或者他们本身就了解一些安全的重要性，都会加一些有用或者没用的限制，用户直接输入可利用的部分越来越少，于是隐式输入就开始受到关注。这里说的并不仅仅是perl cgi，包括现在一大帮人玩的asp注入攻击，还有本来是n年前的技术现在才浮出水面的php注入还有一些其他的攻击手段。仔细回顾一下你就会发现很多都是隐式输入所引起。隐式输入都是不被程序员注意或者容易被忽略的地方。
　　
　　cookie应该算是隐式输入中比较典型的例子，我们就用cookie来说事儿吧......
　　
　　-----------Code Start------------
　　#unsafecodz2.cgi
　　......
　　18 $filename=$query->cookie("namecookie");#**********#
　　19 $filename="$filepath/".$filename;
　　20 open(FILE,$filename);
　　21 while()
　　22 {
　　23 print $_;
　　24 }
　　25 close(FILE)
　　-----------Code Ends------------
　　
　　注意打星号的那一行，这只是提取cookie而已，这的确不是用户的直接输入，但这却是用户可以间接控制的。如果恶意用户通过nc提交如下东东，后果是什么呢？
　　GET /myhome/unsafecodz2.cgi HTTP/1.1
　　Accept: im