做web的安全测试也有些日子了，以前没有到这个版块来过，看了看版面上大家都在讨论工具如何如何使用，而很少讨论安全漏洞的原理，我给大家泼泼凉水，谈谈工具的局限。

　　先说下扫描工具的原理：

　　扫描工具可以看做由两部分组成：爬虫+校验机构。爬虫的作用是搜集整个被采集对象的链接，然后校验机构对这些链接逐一进行验证。

　　然后说扫描工具的局限：

　　局限1：扫描未必全面

　　一个网站，能不能被扫描全面，很大程度取决于爬虫搜集链接的能力。我做过爬虫的测试，所以大致知道爬虫的原理，是对给定的入口地址发起请求，然后从返回的内容中抽取链接，然后再请求抽取到的链接，如此反复。包含在HTML中的链接，很容易被抽取到，但是由js生成的链接，抽取的时候有些难度了，由Flash生成的链接，更是难于被抽取到。此时有人想说图片验证码了吧？我们做测试可以要求网站开绿灯，暂时屏蔽验证码，这个倒可以不考虑。目前ajax技术的流行，更让爬虫搜集链接的能力显得捉襟见肘。所以这暴露出了扫描工具的第一个局限，扫描未必全面。

　　局限2：对屏蔽错误信息的网站效果不好

　　如果你觉得扫描不全面可以通过多分析和从不同的入口地址多测试几遍可以克服的话，这个局限稍微比上边那个有点难度了。这个主要是“校验机构”的局限，校验机构的工作原理是对特定格式的链接或者特定格式的表单匹配特定的模拟攻击用例，模拟攻击。我们知道，攻击是一个请求的过程，也是一个request，而攻击的结果怎么看？只能从response里看了。以SQL注入为例，当发送一个1‘这样的参数值到后台之后，如果返回页面内容中包含了SQLException，那么扫描工具认定它是一个SQL注入漏洞。但是如果网站设置了错误页面，在有异常发生时直接跳转到一个错误页面，告诉你“出错啦！”，然后再没其它信息，采集工具怎么判断是否存在漏洞？难道你去跟研发人员说“麻烦您把错误页面去掉”吗？要真说了，我们高傲的研发人员肯定不会给你好脸色的。

　　局限3：对特定的场景不适合

　　局限3跟局限2多少有些类似，但性质不太一样，局限3是指某些特定场景。扫描工具扫描bug的原理，1和2里叙述的差不多了，这里我们举两个例子吧，看了例子大家看看怎么用扫描工具来发现这俩漏洞，要是不能发现，那是扫描工具的局限了。第一个：有个网站允许用户注册，用户注册后还允许用户修改个人信息，但是修改个人信息的这个地方有个SQL注入漏洞。我们知道，一般修改个人信息的SQL大致是这样的update [userinfo] set password=‘1111‘， email=‘abc@163.com‘ where uid=‘男孩子‘，如果一个用户修改自己密码的时候把密码设为了1111‘--，这样，如果存在SQL注入漏洞，所有注册用户的密码都变成了1111。这里有漏洞吗？有！但是工具能发现吗？除非查看数据库，否则根本发现不了这问题。再看第二个：站内消息我们很多时候都用到，假设站内消息存在XSS漏洞，那么A给B发了这么一段恶意的脚本，但是从A那边看跟普通消息的发送是没什么区别的，所以扫描工具发现不了这个问题，除非再用账号B来登录进行扫描。但是，这个看着简单，实际上操作起来却比较难。你怎么知道扫描工具模拟攻击的时候发消息给了B，而没给C或者D或者E呢？所以这个时限起来也是不现实的。同样道理的还有在外网提交了留言，到管理台审核这种模式，都存在类似问题。

　　以上只是列举了3点，算是提醒大家多注意一点工具以外的事儿吧，测试这个东西，不是拿个工具能搞定的。我说这些不是说大家以后不要用工具，而是要正确的用工具。一个测试申请提交以后，应该首先分析哪些地方可能是工具覆盖不到的，把这些地方先人工检查，剩下的再用工具做全站覆盖扫描。

　　555，写这个花了一个多小时，的1/8没了。不知道说这点有没有用，大家看看一起讨论，一起学习进步吧。