在网络安全方面原理性的东西看起来都是很高深的，而且很枯燥，不及做试验那么爽，那么直观、刺激，其实仔细总结一下收获也是很大的。如果看完下面的能给你一点启发，我的口水也会很欣慰的流下了!以下仅代表本人观点。

    一、变量过滤的重要性

    变量过滤在网络安全中起着越来越重要的作用，一次次令忽略它的人付出了惨痛的代价。从几个例子来看一下，注意文中提到的变量。

    先提一下时下很流行的脚本。两个重大的发现：注入和上传漏洞。从本质上看两者都是一样的――变量过滤不严，只是变量有所不同，被注入的变量有数字型和字符型之分，上传漏洞中利用的主要是上传路径这个变量。下面是几个典型的注入语句：
    (1) http://domain name/list.asp?ID=1 and 1=1(数字型)
    (2) http://domain name/list.asp?Class=喜剧片 and ‘1’=’1’(字符型)
    (3) http://domain name/list.asp?ID=1 and exists (select * from admin)
    ……

    从这些语句中可以看出变量过滤不严与函数是紧密相关的。list.asp处理ID的函数一定对ID未做充分的过滤。语句(1)中是把 ”1 and 1=1”做为一个变量，程序会把这个畸形的ID带到函数里面来处理，list.asp?ID=1的同时执行了后面的查询语句如(3)所示。如果list.asp?ID=1和后面的查询语句都正确的时候才会在IE里显示正确的页面。我们只要验证一下ID是否为数字型就可以避免了，对于字符型的(2)我们就可以采用长度过滤来做限制。难道对程序员来说实现过滤有这么难吗？应该是程序员的一时疏忽而已，换个角度看其实这种疏忽带来的危害，恰恰激励了程序员以后可以写出更好的程序来。

    上传变量的利用就更巧妙了，我在这里佩服一下先！有编程基础的朋友都知道\0在一个数组中的含义，C中的定义数组为：char filepath[ ]=”\uploadface\myface.gif”，若我们定义char filepath[ ]=”\uploadface\0myface.gif”会怎么样？\0就是数组结束的标志，不管是什么语言在解释后都会在数组后面自动加\0用来给系统识别结束的位置，而\0也可以我们自己加进去。在ASP脚本中由于数据的未被封装，我们就可以对数据进行随意改动然后在交给函数处理(其实封装了的同样可以提交非法数据)。在上传文件脚本中的保存文件的典型语句是：Filename=Filepath&Data&Filetype如果前面对Filepath变量未作任何处理，显然我们在给www服务器发送数据时提交一个假的Filepath为”/newmm.asp\0”，那么Filename数组就会变为”/newmm.asp\0”+”20041001”+”.gif”既然\0是结束的标志系统读到\0时就不再往后读数据了那么Filename就是=”/newmm.asp\0”。。。怎么样? HO…HO…再佩服一下。同样的道理后面的Filetype处理不好的话同样后果严重。对付这个过滤不严跟前面的注入不相同，我们即不能用长度filepath来限制，也不能用简单的数字或者字符验证来草率处理。那怎么办？既然是过滤不严，当然就要好好过滤一番了，最好方法的就是锁定Filepath，再加上原有的filetype的处理。看你还能怎么样?

    在脚本安全中变量过滤这么重要，其他方面呢？这在看看”溢出”，一个可爱又可恨的字眼。微软可能现在还没从RPC的恶梦中回过神来。REMOTE PROCEDURE CALL (RPC)是运用于WINDOWS操作系统上的一种协议，它提供相互处理通信机制，允许运行该程序的计算机在一个远程系统上执行代码。RPC协议本身源于OSF (OPEN SOFTWARE FOUNDATION) RPC协议，后来又另外增加了一些MICROSOFT专用扩展功能。 其中RPC的DCOM接口用来处理由客户端机器发送给服务器的DCOM对象激活请求(如UNC路径)。WINDOWS RPC在通过TCP/IP进行信息交换过程时，在为DCOM服务提供__REMOTEGETCLASSOBJECT接口时，未对数据包中的结构指针参数做有效性检查，因此收到的数据包中该指针为NULL的时未能正确处理，导致系统直接引用此地址（已经为NULL）做读写操作，导致内存访问违例，RPC服务进程崩溃。而RPC服务是MS WINDOWS中一个重要的服务，他开放的135端口用于DCOM的认证、EPMAPPER管道用于RPC端点的映射，并默认为系统信任，如果一个攻击者能够以低权限在被攻击机器上运行一个程序，在RPC服务崩溃以后，就可以通过劫持EPMAPPER管道和135端口的方法来提升权限或获得DCOM客户端认证的信息。至于怎么抓包、提交数据，当然不会用我们的NC了，但是原理是一样的，就是给其中处理不当的变量赋特殊值(千万你不要根我说你想加 ”\0” 哦！)，然后提交给目标机来处理就OK了，只是网上比较多的是别人编译好的程序，它已经把抓包、提交的功能合在一起了，建议大家看一下程序的源码，肯定受益非浅啊！还是要说一下过滤这个变量就那么难吗?微软的程序员不会连IF (??!=NULL)都不知道吧?也许是程序员疏忽而已(不知道会不会被BILL开除，呵呵。。。)后来又发现的超长文件名溢出的问题，变量过滤不严的毛病就更明显了，还有现在的JPEG漏洞，我虽然没有看到详细的说明，但是可以推测肯定又是对WINDOWS对JPEG格式的文件处理时某个变量又出了问题。。。HO...HO，微软又要做恶梦了，阿弥陀佛!!!。再比如SERV-U MDTM命令，格式：MDTM filename，当我们提交后面的FILENAME为超长时，就会溢出，特殊构造的话就会有更大的威胁。。。。。。这个怎么利用，大家肯定比我更清楚，由于我们这里主要不是说如何溢出所以就点到为止了.