本文其实并不会详细描述0day的各种挖掘技巧，因为要详细写的话各个方面都足够写成一本书了，而且我也只是个学习中的菜鸟，写不出那么多东西，这里只是谈谈我个人的一些经验和理解。

 

暂且分成两类情况吧：开源型和非开源的程序。其实这里用开源两个字并不准确，原因很简单：很多商业用的web程序即使其程序文件可以直接查看源码，但是你要想搞到也不是很容易的除非你刚好渗透了一个用该程序做的网站并将其代码打包带回了。好吧，说的明白点：这里的开源可以理解为—你能直接查看源码。我们相信，一切程序的bug都是代码出的错。不管是红能bug还是安全bug，都是代码写的有问题。因此，如果能得到目标的源码，事情在某种程度上会变得相对容易点，这种情况通称白盒测试。尽管白盒可能会发现一些与之相对的黑盒发现不了的问题（事实上很多自动化的漏洞扫描工具在扫描结果中都会遗漏不少实际存在的漏洞）但不等于白盒能完全取代黑盒。原因很简单：尽管电脑不能完全代替人脑，但是大规模的在某种程度上带有重复性质的工作交给机器处理会节省很多资源。白盒的价值在于发现黑盒所发现不了的隐藏相对较深的漏洞，比如那次的DZ7.2事件。但对于显而易见的问题用白盒就有点大材小用了，比如：

 

dim rs,sql,id

 

id=request(“id”)

 

set rs=server.creatobject(“adodb.recordset”)

 

sql=”select * from user where id=”&id

 

rs.open sql,conn,1,3

 

>

前面已经说过，这里不细谈如何挖掘漏洞，事实上挖掘web脚本漏洞只要你熟知各类漏洞的概念以及成因，在多加练习之后自然就能得心应手。比如：sql inj.的成因是因为对动态交互的变量没有进行足够好的过滤或者净化，导致恶意用户能提交精心构造的sql查询语句获得各种期望获得的数据或信息。理解了这段话，就能很轻易理解上面那段代码存在sql inj.漏洞。虽然这是最简单的情况，但万变不离其宗。

没法获取源码的，典型的是编译的二进制文件，对于这些程序通常采用fuzz test。（不过对于.net和java写的也可以反编译得到源码）。Bill Gates曾经说过：任何用户的输入都是有害的。其实恶意用户所能控制的也就是能让其提交数据的地方了，当然我们可以让思路在系统化一点：首先，一定是代码出了问题；其次，程序做出来肯定是为了提供满足用户的某一种或者某几种需求的功能；最后，既然代码出了问题，那么对应的在这些功能的运作上肯定有某一处或者某几处存在受攻击面。好了，接下来形象化一点：比如FTP程序，首先肯定是问了传输文件的，但是如果不允许匿名访问的话（很多情况下都这样）就要用户提交身份验证，也就是最基本的用户名和密码，好了，用户可控制的地方出现了—提交的用户名和密码，这些都是变量，是用户可控制的变量，如果程序对这些变量处理存在问题呢？比如：我们输入过长的用户名或者密码会不会导致stack overflow之类的？再比如：浏览器程序返回给用户的是标准的html文档，我们假设一下：如果浏览器对某一种或者某一些html标签的组合处理不当呢？最大可能是导致程序崩溃的拒绝服务。当然，浏览器可能会出现的问题不止如此，跨域问题会是web2.0时代的热门话题—我是这么认为的。综上：全面了解目标程序的功能—然后考虑各种功能在处理上可能存在的问题—再针对性测试，是一条可行的思路。