|
报告对象 记得犹太文化里有个谚语就说过：世界上最难的有两件事：一是把别人口袋里的钱拿到自己的口袋里，二是把自己脑袋里的东西塞到别人的脑袋里。这说明达到思想上的认同绝非易事。如果您不知道该报告的受众和其关注点，那么从报告人自身的角度定义一个报告的脉络or结构是非常重要的。这样才会让读者有“带入感”并随之产生共鸣。 当然，根据我的经验，至少有两种类型的人会阅读我们的测试报告：管理层和IT技术人员。而实际上管理层是不愿通篇阅读当然也是读不懂测试报告的。他们只想通过目测漏洞列表条目的数量和测试结论，来快速获悉“我们现在到底安不安全?”而IT技术人员则对会各条漏洞分析尤为重视。他们时常怀揣着一颗“既觊觎系统在测试后并无重大漏洞;又希望漏洞程度与整改建议能全面且合理”的待嫁之心。所以我们要花时间搞清楚要报告的对象，并设身处地的从他们的角度来换位思考，做到言之有物、言之凿凿。能够实现“老总看了会沉默，IT看了会流泪”那就厉害了。 封面 对没看错，我们从封面讲起，要注意什么呢?要标明整个报告的“等级标识”和“测试日期”这两个重要元素。 目录 记得小时候读书的时候，语文老师就教育我们：“拿到一本新书的时候要先看目录，以后长大了去某公司查找书籍也要如此。”同理，目录可以让阅读此报告的人对报告的整体架构有个宏观的认识，也可以快速跳跃的到其感兴趣的章节和部分。 内容摘要 怎么听上去有写论文的赶脚?对，只不过不同的是：一般论文在这里尽量体现其通篇最有技术含量的元素，以便更为方便的被检索到。但咱们的报告摘要，则应该尽量避免使用专业术语。因为真正会阅读这部分的管理层金主(非技术类管理人员)可要比技术大牛可多得多哦。当然该部分也可以方便被直接摘录到PPT里，进而在会议上分析与传阅。其实全称应该叫做执行摘要(Executive Summary)，也就是汇总性的告知测试了什么、发现了什么、而且是由于什么所导致的。然后就是所发现的漏洞的一个从高到底列表。当然，这里有个小贴士给大家：虽然测试报告命中注定是汇报IT系统和人员的“缺点”，但如果能在摘要中列举出抗攻击成功和安全措施到位的地方，则会在体现测试的客观性和全面性的同时，也能给报告对象带有些许安慰或成就感。毕竟谁都不想看到自己的系统和员工是那么的一无是处。而在执行摘要的最后应该是一个结论，即明确指出是该系统是安全还是不安全。 上述这些都是报告开篇的重要部分，应当能够脉络清晰的呈现在一页A4纸上，让“读者”一目了然的知道接下来要做什么。 测试流程 在E文里，这个部分有个美丽的名字叫做“Technical Storyline”。对，就是最近热播剧《West Word》里，老戏骨们争得头破血流的storyline。我们可以画出带有各种条件判断和步骤框图的测试Flow Chart，它既可以体现咱们的专业水平，又能彰显测试思维的缜密性。另外，我们还可以在必要时阐述一下涉及到评判标准之类的方法论，以增强逻辑性。 工具列表 这里主要包括版本和功能的简要描述。其好处是：如果有人要重现您的测试，则他们可以籍此确切的找到您使用的工具，实现测试的可重复性。 报告主体 这一部分在整个报告中的技术成分含量最高，报告的正文应当包括所有检测到的漏洞细节。即：如何发现到漏洞、漏洞可以如何利用、以及其被利用的可能性有多大。并且还应该尽可能的逐条给出切实贴合的修复建议。在表述顺序上可以有如下几种“打开”方式： · 以严重等级：从高到低，例如：从SQL的注入漏洞一直罗列到源代码中留存的，尽管被注释掉的信息。 · 以网络架构：从外到内，例如：可以参考我们前面各期漫谈所递进介绍的网络拓扑结构的顺序哦。 · 以系统功能：从点散开，例如：将系统中所有涉及到侦听、嗅探的各种测试都描述到位之后，再描述所有涉及密码破解的测试结果。 哥本人喜欢用的方式是以填表的形式予以呈现，比如在每个表格里都固定包含的表项信息有：漏洞名称、等级程度、被利用的可能性、危害范围和建议等。而且要善用rich formatting(即不同颜色、字体、字号和效果等)，以达到醒目和易记忆的效果。当然也可以通过软件来自动生成一些饼图或柱状图，以体现各种占比。毕竟有图有真相、图文并茂，才更有说服力。 附录 这里可以添加一些未尽之言的内容。比如：一些测试原理与依据的支撑材料，参加测试人员的资历和项目经验，以及一些必要的且包含有时间戳和系统特征信息的佐证截屏，甚至是一些术语说明列表等。 免责声明 正如《阿甘正传》里的那句：“生活就像一盒巧克力，你永远不知道下一颗是什么味道。”我们在愉快的提交了测试报告后，是无法知道它被用来做什么以及会给自己的工作带来什么的。所以如果你是作为第三方involve到这个测试中的话，最好是在最后或是扉页处撰写一个免责声明，必要时可以附上有高层签署的该渗透测试同意书。 | 
发表于 2017-5-23 10:35