【51CTO.com原创稿件】自从上一期，我们开始谈到渗透测试以后，就有细心的朋友心生疑问的私信我：“上次聊的渗透测试怎么和我们平时接触到的不太一样啊?我可能看了假的‘廉环话’吗?”看来我要赶快出来澄清一下了：朋友，您看得没错也问得非常好。因为上次是从完全模拟陌生攻击者的角度来进行的“黑盒”盲测;而大家平时工作中与审计人员所接触到比较多的应该是“灰盒”测试。那么为了保持本漫谈的完整性，哥对这种“灰帽子”的渗透测试也和大家聊聊吧。借用我当年高中老师们的那句口头禅：“来，我们直接看重点!”
其中准确性上容易失真的当属“社会工程学与安全意识”测试了。由于可能事先走漏风声、或是采集的“样本”不够丰富、亦或测试的时间不够充沛，都可能产生企业员工安全意识强的假象。所以说技术只能帮你发现客观存在的漏洞，意识则可以决定漏洞如何被利用。就算企业通过了此环节的测试，也只是一个短暂平衡态，或根本就是一个“幸存者偏差”。因此相关培训和B轮、C轮测试必须成为一种常态。
最近很流行“下半场”的说法，那么廉哥接下来就继续跟大家来聊渗透测试的下半场—测试报告吧。经过了前面模拟攻击者的行为测试，我们安全人员需要最终整理出一份测试报告。就像那个经典的说法：“人们想买的不是一个钻孔机，而是想在墙上打一个孔”一样，请记住：我们报告不能写得太文艺、也不能写得过于学术化，毕竟它只是一个说明企业安全态势的工具。下面具体我们来看看每个章节应该注意些什么吧。
报告对象
记得犹太文化里有个谚语就说过：世界上最难的有两件事：一是把别人口袋里的钱拿到自己的口袋里，二是把自己脑袋里的东西塞到别人的脑袋里。这说明达到思想上的认同绝非易事。如果您不知道该报告的受众和其关注点，那么从报告人自身的角度定义一个报告的脉络or结构是非常重要的。这样才会让读者有“带入感”并随之产生共鸣。
当然，根据我的经验，至少有两种类型的人会阅读我们的测试报告：管理层和IT技术人员。而实际上管理层是不愿通篇阅读当然也是读不懂测试报告的。他们只想通过目测漏洞列表条目的数量和测试结论，来快速获悉“我们现在到底安不安全?”而IT技术人员则对会各条漏洞分析尤为重视。他们时常怀揣着一颗“既觊觎系统在测试后并无重大漏洞;又希望漏洞程度与整改建议能全面且合理”的待嫁之心。所以我们要花时间搞清楚要报告的对象，并设身处地的从他们的角度来换位思考，做到言之有物、言之凿凿。能够实现“老总看了会沉默，IT看了会流泪”那就厉害了。
封面
对没看错，我们从封面讲起，要注意什么呢?要标明整个报告的“等级标识”和“测试日期”这两个重要元素。
目录
记得小时候读书的时候，语文老师就教育我们：“拿到一本新书的时候要先看目录，以后长大了去图书馆查找书籍也要如此。”同理，目录可以让阅读此报告的人对报告的整体架构有个宏观的认识，也可以快速跳跃的到其感兴趣的章节和部分。
内容摘要
怎么听上去有写论文的赶脚?对，只不过不同的是：一般论文在这里尽量体现其通篇最有技术含量的元素，以便更为方便的被检索到。但咱们的报告摘要，则应该尽量避免使用专业术语。因为真正会阅读这部分的管理层金主(非技术类管理人员)可要比技术大牛可多得多哦。当然该部分也可以方便被直接摘录到PPT里，进而在会议上分析与传阅。其实全称应该叫做执行摘要(Executive Summary)，也就是汇总性的告知测试了什么、发现了什么、而且是由于什么所导致的。然后就是所发现的漏洞的一个从高到底列表。当然，这里有个小贴士给大家：虽然测试报告命中注定是汇报IT系统和人员的“缺点”，但如果能在摘要中列举出抗攻击成功和安全措施到位的地方，则会在体现测试的客观性和全面性的同时，也能给报告对象带有些许安慰或成就感。毕竟谁都不想看到自己的系统和员工是那么的一无是处。而在执行摘要的最后应该是一个结论，即明确指出是该系统是安全还是不安全。
上述这些都是报告开篇的重要部分，应当能够脉络清晰的呈现在一页A4纸上，让“读者”一目了然的知道接下来要做什么。
测试流程
在E文里，这个部分有个美丽的名字叫做“Technical Storyline”。对，就是最近热播剧《West Word》里，老戏骨们争得头破血流的storyline。我们可以画出带有各种条件判断和步骤框图的测试Flow Chart，它既可以体现咱们的专业水平，又能彰显测试思维的缜密性。另外，我们还可以在必要时阐述一下涉及到评判标准之类的方法论，以增强逻辑性。
工具列表
这里主要包括版本和功能的简要描述。其好处是：如果有人要重现您的测试，则他们可以籍此确切的找到您使用的工具，实现测试的可重复性。
报告主体
这一部分在整个报告中的技术成分含量最高，报告的正文应当包括所有检测到的漏洞细节。即：如何发现到漏洞、漏洞可以如何利用、以及其被利用的可能性有多大。并且还应该尽可能的逐条给出切实贴合的修复建议。在表述顺序上可以有如下几种“打开”方式：
· 以严重等级：从高到低，例如：从SQL的注入漏洞一直罗列到源代码中留存的，尽管被注释掉的信息。
· 以网络架构：从外到内，例如：可以参考我们前面各期漫谈所递进介绍的网络拓扑结构的顺序哦。
· 以系统功能：从点散开，例如：将系统中所有涉及到侦听、嗅探的各种测试都描述到位之后，再描述所有涉及密码破解的测试结果。
哥本人喜欢用的方式是以填表的形式予以呈现，比如在每个表格里都固定包含的表项信息有：漏洞名称、等级程度、被利用的可能性、危害范围和建议等。而且要善用rich formatting(即不同颜色、字体、字号和效果等)，以达到醒目和易记忆的效果。当然也可以通过软件来自动生成一些饼图或柱状图，以体现各种占比。毕竟有图有真相、图文并茂，才更有说服力。
附录
这里可以添加一些未尽之言的内容。比如：一些测试原理与依据的支撑材料，参加测试人员的资历和项目经验，以及一些必要的且包含有时间戳和系统特征信息的佐证截屏，甚至是一些术语说明列表等。
免责声明
正如《阿甘正传》里的那句：“生活就像一盒巧克力，你永远不知道下一颗是什么味道。”我们在愉快的提交了测试报告后，是无法知道它被用来做什么以及会给自己的工作带来什么的。所以如果你是作为第三方involve到这个测试中的话，最好是在最后或是扉页处撰写一个免责声明，必要时可以附上有高层签署的该渗透测试同意书。
那天哥陪一个小小孩下四分之一的围棋盘。孩子一开始就口中念叨着“金角银边草肚皮”那句口诀。这使我突然顿悟到：我们信息安全与下围棋也有相通之处啊。系统的安全同样也是从边界防护开始着手的(曾记否?咱们漫谈就是从边界讲起的哦。);而渗透测试则更像是我们平时“打棋谱”一样，不断通过模拟攻防、揣摩改进以培养对整体系统安全的全局掌控能力。另外，与要把对方的攻击性棋子消灭干净并将死才为胜利的象棋不同，围棋讲求的是：无不同职能棋子的区分，双方棋子尚在棋盘上的情况下，只要在数量上达到可预见的制衡，便可判定胜负。因此，对于各种攻击，我们做信息安全的也无法完全阻止，更不存在一劳永逸之法;我们只能将“魔高一尺，道高一丈”动态化且常态化。想着、想着我居然连输了孩子两盘……
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
