web测试知识拓展

web安全往具体里说也包括很多，渗透测试是其中很重要的一个方面。我在腾讯一年半的时间里，做的都是这个事情。从本质上来说，web渗透测试就是一种黑盒测试，但比起客户端软件来说，做起来就容易很多。这是由web应用的特点所决定的：传统上，每一个web程序都是一个功能单一、体积小巧的独立程序，输入有限，输出有限，能访问的资源也有限。这样无论是普通的功能与性能测试，还是安全渗透测试，都比较容易进行。

　　总的来说，web渗透测试就是给目标程序提交各种“变态”的参数，看这个程序能不能访问到正常情况下不允许访问的数据、文件，是否输出了一些不太安全的内容到返回页面上。所需的全部家当呢，就是一个浏览器了，可能还得加上一个可以查看HTTP请求的工具。

　　比如说，我们查看山水的一篇帖子，是在浏览器地址栏里面输入这样形式的地址来进行的：

　　http://bbs.whu.edu.cn/bbsrecon.php?id=2525

　　在这里，bbsrecon.php就是一个web程序，id就是这个程序的输入参数，2525就是一个具体的输入数据实例。我们可以猜测，这个web程序以这个id为索引，去后台数据库里查找一条匹配的记录，然后把内容到一个网页框架里，再返回来给我们的浏览器；也有可能，论坛的帖子是以文件形式存放的，这个web程序用这个id形成一个具体的文件名，然后

　　首先，这个程序是一个黑盒子，我是不知道它里面的具体实现的。但是我可以通过一些固定的模式来测试去得到足够的信息来猜测它是怎么做的。这样的模式是通用而且非常简单的：我在看到“?id=2525”这样形式的链接地址时，就会习惯地在参数后面多加一个引号（或者是双引号），再按下回车让浏览器发送这样的一个请求：

　　http://bbs.whu.edu.cn/bbsrecon.php?id=2525' 　　为什么是单双引号呢？因为这个符号可以构成一个很奇妙的测试用例：（1）原本是一串数字的2525，现在因为末尾的引号而变成了一个不合法的数字，程序怎样处理一个原本期望是数字串但实际却含有非数字字符的输入呢？（2）对于使用数据来做存储的应用来说，它极有可能利用输入参数来构造一个SQL语句传给后台数据库，才能最终完成的请求，我们可以猜想这个语句具有这样的形式： select * from article where aid=2525 。而我们额外添加的引号有可能原封不动地添加到这个SQL语句的末尾----而这如果传到DB中去的话，势必会引起一个语法错误，这时的web程序，又是怎么应对呢？（3）如果使用文件来做存储，它可能会把id=2525映射成一个实际的路径：/data/bbs/article_2525.html，类似这样的形式，那么多余的一个引号如果也原样传进来，最后构成的一个路径十有八九是不存在的文件路径，读取文件失败，程序又会怎样响应呢？

　　在考虑不周的程序中，非正常的输入会导致程序运行失败（通常返回一个“内部服务器错误”的页面），有些程序员会把错误信息打印出来，比如说类型不对啊，SQL语句非法啊，读取什么文件失败啊----在这一步，程序已经开口告诉我们很多信息了。在网上有非常多的站点都存在这样的问题的，不信你可以试试（只需简单地在地址栏的参数后面加一个引号）。

　　也有可能程序对错误进行了处理，在操作失败的时候输出一个提示信息（比如说，对不起，系统繁忙之类的），从而掩盖了底层的出错信息。但是如果程序没有对输入进行过滤的话，我们还是有办法知道的：因为一个失败的操作所得到的结果和一个成功的操作所得到的结果是不一样的，这种不一样必然又会反映到最终返回的页面上。我们要做的，就是用其它的的例子继续测试，直到我们能够确认它有问题或者没有问题为止，而这些用例的数量是很有限的，可以在数分钟内就能测试完毕。

　　比如说，对于文件类型的存储，要确认是否有问题的话，就在参数后面有序地添加../序列（我们知道这会返回到上一层的目录），并指向一个可能的文件（比如windows的c:/boot.ini，linux的/etc/passwd），一直到5~6层（再高也不太可能了），如果有漏洞的话，它就会在某一层成功，打开你所指定的文件，并把这个文件的内容读取出来返回到你的浏览器上。这就是文件型漏洞的测试方法。而对于SQL型呢，你就在脑海中想着一个正常的SQL语句，后面跟着你输入的参数，你怎样在这个SQL语句中“插入”其它的语句来控制它呢？用“ and 1=1 ”和“ and 1=2 ”来对比一下如何？熟悉SQL的同学会明白，and 1=1是一个为真的条件，附加在原SQL语句后对查询结果无影响，但and 1=2是一个为假的条件，附在原SQL语句后却会使得整个查询返回一个空集。DB有没有数据给web程序，是可以在浏览器上一目了然地看到的，所以我们就能知道我们能否通过URL参数来控制后台DB。这种漏洞就是SQL注入漏洞，网上很多入侵的案例，都是通过这种漏洞来进行的。大家想验证一下的，也可以在google中找些来试下（比如说：在google中查找 inurl:id inurl:php就可以找到不少xxx.php?id=yyy形式的链接）。这种漏洞还是非常普遍的。

　　至于另外一种比较典型的漏洞跨站脚本漏洞，就是在参数后面加入一段HTML的代码，比如说这样的形式id=2525<script>alert('xss')</script>，看最后返回来的页面中有没有包含你输入的这段HTML代码，如果有的话，就是有跨站漏洞了。对于论坛、发帖等形式的也一样，在输入中包含HTML代码，保存，如果最后这段代码能够原封不动地显示出来，那就是有这个问题了（也就意味着，你也可以制造一只类似于百度蠕虫一样的跨站蠕虫了）。

　　嗯，基本上，web测试的原理就这样，不过要做到纯熟，还是需要很多的练习，并且要多看一些有深度的文档，这样才有进步。