我们可以拿最简的XSS来做举例，可以分以下几种情况讨论：

　　* 仅仅能实现弹窗，也就是说，也许是某些限制的原则，仅能alert，那么，归结为过滤不严格且是其中最低危害等级的；

　　* 非存储型，在URL里构造大量内容才能造成一定危害，这种情况相对来说易暴露，危害等级虽然高，但相对难实施，所以综合下来等级也只能达到中；

　　* 存储型，直接POST了javascript到某个页面，访问者可直接被盗取敏感数据，此时应该是XSS里得分相对最高的一个级别。

　　以上几个级别和对应的分数，我把他们定义为“实施等级”，实施等级的得分再与上面的“中间分数”进行二次计算，才是最终得分，这样，大概有这么一个表单：

注：以上只是一个示例说明，具体算法和权重、分数等，需根据划分的测试项和大分类自身的定义来做细化

　　当然，这只是一个简易表格，还可继续完善，例如：测试项对应的检测工具、对应的参考资料、CVE链接等等，都可以做入其中，这样，测试人员只需一张表格便可有完整的测试指导，而对于用户来说，只要表格中的一些测试项、易用性、实施等级等资料，即可了解测试工作包括了什么，测试的内容危害是什么，最终的分数是怎么计算的等他所关心的问题。

　　BTW：如果有条件的话，最好能在表单中或是表单外，针对每个测试项附加一个用例库，而用例库除了初次添加外，还应在每次测试完毕后根据具体项目情况来完善现有用例库，当用例库达到一定程度的时候，根据每次的项目目标，即可对用例库进行行业分类，到那个时候，渗透测试的行业化方向，在用例库中就能清晰的看出来了。

　　5、基于业务的白盒渗透测试

　　其实，我最终想说的重点，应该都在该部分，在黑盒测试部分，无论从技术层面做的如何细致，都是难以完全贴近用户真实业务情况的，而其结果也不过是一个纯粹的技术数字而已，仅仅对技术层起到一个“通用性”的指导作用，很难拔得一定的高度，所以，我认为，细化现有渗透测试的技术流程和技术层面虽然是必要的一个过程，但也仅仅是一个中间过程，在目前的“可改进范围之内”，基于业务的白盒渗透测试才应该是最终渗透测试的一个必然方向。

　　那么，怎么样进行“基于业务的白盒渗透测试”（以下简称“白盒测试”）呢？

　　第一步：了解业务特性、熟悉业务流程

　　在此需要做以下的工作：a、梳理业务流；b、梳理业务逻辑；c、确认业务节点；d、利用业务流和业务逻辑串联业务节点。

　　其实，这就是之前我所写的《技术乱谈：从客户端到业务系统》文章中后半部分关于业务系统评估及防护方法的前几步，也就是说，如果基于业务进行过类似的评估工作的话，那么，实际上那些输出已经可以作为此步的输入了。

　　第二步：导入管理风险

　　管理调研这部分，每个人做法不一样，因此很难有一个通用表单或工具来做集中导入。

　　但是，对于有风险评估经验的人来说，做一个case-by-case的东西却不太困难，我的大概思路如下：

　　* 串联业务流上的节点脆弱性，将节点与业务流串联完成之后（以下内容可先参考《技术乱谈：从客户端到业务系统》），节点上的脆弱性也可以按照类似的方法进行串联，简单举例来说，如，业务流与节点的串联关系为：A — B（TCP 80） — C（TCP 1521），也就是说，从A发起访问，到B的TCP 80 作为一个技术指标，然后在从B跳转至C节点的TCP 1521，这样一个业务流程完成，当然，还有反向的，就不再列举。

　　同时，我们会在A、B、C三个节点上分别做脆弱性的挖掘工作（与传统技术评估类似），而依照A-B-C现有流程，结合挖掘出来的脆弱性，就可以将一条攻击路径勾画出来，例如：利用A的某漏洞，可跳转至B，然后再如何如何跳转至C，甚至通过破坏现有业务逻辑的情况下来完成攻击也是可以的。

　　* 串联管理上的脆弱性，至此为止，所有的“可能性”都是基于技术层面的，于是，还需要加入管理层面的“可能性”，例如：传统意义上，我们认为针对节点A的侵入都是通过远程的方式，但如果A上存在一个IE漏洞，而安全操作手册里又未对节点A的本地操作做类似“不能使用该服务器访问WEB页面”的限制的话，那么，实际上节点A就存在了“通过利用钓鱼方式来侵入节点A”的一个可能性，实际上这就是一个导入管理风险的过程。