如何写好一篇漏洞报告（国外篇）

点击上方蓝字可以订阅哦

如何写好一篇漏洞总结报告，这一直都是一些应用开发公司经常忽略的重要事情，一篇好的漏洞总结报告可以有效帮助开发人员，减少寻找和解决漏洞的时间。

接下来我就开始讲述如何该写好一篇漏洞总结报告，这样你就可以在看完报告后短时间内解决漏洞问题，同时也可以避免在软件项目过程中遭遇公关问题。那么首先来对比一下错误和正确的漏洞总结报告。

一个错误的漏洞总结报告是什么样的？

在开始分析之后，先为大家介绍几个漏洞基本概念，CVSS(Common Vulnerability Scoring System)即通用漏洞评分系统 是安全内容自动化协议(SCAP)的一部分，分值（0-100)，同时为行业公开标准,其被设计用来评测漏洞的严重程度 帮助确定所需反应的紧急度和重要度。CVSS同CVE一同由美国国家漏洞库(NVD)发布并保持数据的更新，CVE(Common Vulnerabilities and Exposures)为漏洞和暴露确定了唯一的名称以及一个标准化的描述，同时实现更好的协同工作。

下面我们就来一起分析下错误漏洞总结报告，我们就先来看看错误漏洞总结报告是什么样的。请试着想象这样一件事情，我们搭建了一个有关球迷的社交网站，在一次网站程序升级检测之后，质量保证专员在JIRA上填写漏洞总结报告。下面这张图片就是例子

第一眼看过去这篇报告似乎一切没有问题，不是吗？那么到底还缺少什么内容呢？下面我们就一起来分析一下

漏洞编号（ID）：当你在JIRA网站上填写漏洞总结报告时，网站会默认分配给你一个编号，这一块没有什么问题。

漏洞摘要：该信息往往位于编号信息下面，但这篇报告却没有一语中的，报告中虽然提及了漏洞影响的用户类型，但没有具体说明是哪一种类型的漏洞。如果一个Web开发者看到这样一篇报告，就会提出很多的问题并要求对方来澄清这些疑问。

漏洞详述：很明显测试人员没有提供关于应用程序版本和测试环境的任何数据，我们在下面的文章将会详细描述这一点，至于漏洞优先级问题，测试人员通常会优先分配优先级，以后可能会根据实际情况改变优先级。对于目前国内提交漏洞优先级，需要说明一下，如下：

1)高危安全问题：

1、直接获取业务服务器权限的漏洞。包括但不限于任意命令执行、上传获取webshell、直接导致严重的信息泄漏漏洞。

2、包括但不限于核心DB的SQL注入漏洞（涉及用户数据、订单数据、交易数据），直接导致严重影响的逻辑漏洞。

3、包括但不限于任意帐号密码更改漏洞。

4、越权访问，仅限于重要业务线批量获取订单类信息的漏洞(敏感数据明文)、用户数据信息（明文）、绕过验证直接访问后台、重要后台登录弱口令。

2)中危安全问题：

1、需交互才能获取用户身份信息的漏洞。

2、包括但不限于任意文件读、写、删除、下载等操作。

3、包括但不限于绕过限制修改用户资料、执行用户操作，较严重的信息泄漏漏洞

4、包括但不限于批量获取用户类、订单类信息的漏洞。

5、非核心业务SQL注入，不涉及用户数据、订单数据、交易数据，按中风险处理

3)低危安全问题：

1、普通逻辑漏洞；普通信息泄露；需交互才能获取用户身份信息并且有一定利用难度的漏洞。

2、Discuz 漏洞问题均按低风险处理(discuz非qunar主要业务)

3、批量下订单、发垃圾短信、加关注按低风险处理

4、越权访问，包含敏感信息且打码，按低风险处理

5、代理商弱口令及密码等信息通过云盘、笔记、QQ群备注等泄漏的按低风险处理

6、代理商及合作方后台地址外泄导致暴力破解，按低风险处理。

7、猜测或遍历网站注册用户，按低风险处理

4)通常忽略的问题：

1、不涉及安全问题的bug，包括但不限于网站产品功能缺陷、页面乱码、样式混编等。

2、不会直接带来安全问影响，包括但不限于绕过WAF对业务无影响的，Self-XSS，非登录相关的URL跳转，非敏感操作的CSRF，非敏感信息的JSON Hijacking，无意义的源码泄漏、程序出错而暴露出来无安全影响的信息、内网IP/域名泄漏，以及需借助中间人攻击才能实现的问题。

3、无法重现的漏洞、不能直接体现漏洞的其他问题。包括但不限于纯属用户推测的问题（需要案例）。

4、厂商内部自行发现的，厂商SRC已知的，第三方漏洞平台报告过的漏洞做忽略处理，且厂商提供相应截图（其中：高危：4小时，中危：14天，低危：28天）。

5、第三方已披露的漏洞（基础应用0day，开发框架0day等），距离公告期两天以上且厂商已知晓的。

6、由于已经对关键位置实施HttpOnly限制，XSS漏洞暂不接收（后台盲打类xss除外）。

7、无线订单链接越权查看（用户等信息打码，不能遍历）的按低风险处理

漏洞描述：这块是出现问题最多的地方，在这一部分，测试人员应该按照重新配置、实际结果和预期结果的步骤提供漏洞相关信息。漏洞总结报告就是应该提供有关漏洞的详细信息，如果质量保证专员不能有效的再现漏洞问题，那么看到这篇漏洞报告的软件开发人员就需要多花时间在寻找漏洞问题上。

在看完上面截图信息之后，Web开发人员将立即询问负责编写报告的人使用了哪些登录凭证，如管理员信息、测试用户信息以及版主信息（含BBS模板网站常见）。除此之外，还需要知道出现服务器漏洞（本地环境）问题，简单来说，这种情况一般出现在测试服务器（https://testing-bugs.sprinklebit.com），或生产服务器（https://sprinklebit.com）。还有一个概念大家需要了解，漏洞管理三要素，即准确性、时间以及资源。

测试人员应该提供预期结果，这些细节可以帮助开发人员（有些没参与其软件开发人员对于程序细节不清楚）快速解决这个问题，但我们在报告中没有看到直观的漏洞数据统计图形，比如一些附加图形图像。

如何将一篇糟糕的漏洞总结报告改进？

请看下面这篇报告的截图，这篇漏洞总结报告就比之前的那篇好些。

第二篇和第一篇有什么不同？主要是第二篇的报告对于细节描述更加详细具体，Web开发人员可以根据报告内容对程序进行修改。下面就来说明一下第二篇报告改进的地方，测试人员在报告中描述了重要细节，“聊天功能——创建临时会话的群主不能重命名它”，当然这里面还有其它一些有价值的信息，诸如受影响软件版本号、运行环境以及修复版本信息。

测试人员提到了检测出漏洞的应用程序版本，同时还指出当时测试环境，这样就可以很清楚的了解网站当前运行环境版本。之前描述的步骤中重现是非常重要的，它

可以显示必要的网站登录数据、网站相关软件版本以及按钮说明。实际结果虽然出现在截图中，但测试人员并没有忘记提及预期结果。

在这里强调的一点是，所有漏洞总结报告都应该按照统一规则编写，漏洞总结报告在追踪漏洞方面是非常实用的。

下面我就来介绍一下如何写好一篇高质量的漏洞总结报告，以方便开发人员更高效的解决漏洞问题，最后当漏洞总结报告上的问题迅速解决的时候，你设计的应用程序将会从中获益。

写好一篇高质量漏洞总结报告的诀窍

漏洞总结报告主要是向开发人员澄清一个明确的问题，同时有助于开发人员开发整个项目。在质量保证团队开始编写漏洞报告的时候，他们应该了解以下问题的答案

什么?-应用程序发生了什么事情？

如何？-我们点击/运行程序不发生错误？

在哪里？-到底在应用程序哪个位置出现漏洞?网页/服务器?

下面就开始讲解一种编写漏洞总结报告的样板，并拿一个网站举个例子。

漏洞编号

测试人员可以在 Bugzilla、JIRA等平台编写报告，如果你选择在这些平台编写报告，通常会得到一个编号。另外测试人员也可以手动编写一个编号，这样做比填写完整标题的方案，很显然前者可以节约开发人员开发时间。

在实际生活中，没有人会手动编写一个编号，如果你一定要选择手动编写，可以考虑利用应用程序名称缩写，SprinkleBit就可以用SB-WEB代替，SB-MOB则表示该应用移动端版本。另外，测试人员需要为漏洞加索引编号。

正确：sb-web-121或sb-mob-231（尽量将应用程序运行哪种环境表达出来）

错误：我的网站-#87123或简单标记#112

开发人员有时需要同时处理多个项目，所以设置一个一目了然的漏洞编号，这样可以清楚的表达是哪一个应用程序出现问题。

漏洞摘要

在JIRA网站平台编写报告，需要填写一个标题，这就需要了解报告摘要内容之后才能做这件事情，摘要可以说是漏洞总结报告最核心的部分。对于初学者，我建议使用短信息来填写标题，漏洞摘要通常是以简短的语言描述问题的关键，JIRA 中的项目进展分级为Epic（史诗）->Story（故事）->Task（任务），Epic 可以说占用你在JIRA平台报告中大部分信息，如之前聊天或用户个人资料部分分析，你需要提示测试人员不能带有自身情绪以及主观意见，同时以简短的方式来描述发生了什么事情。

正确表达方式：关于公司屏幕出现问题，屏幕顶部出现红色条纹，还有屏幕中的彩色布局不协调问题。

错误表达方式：屏幕布局有问题/屏幕出现问题

漏洞详细信息

我作为经验丰富的质量保证专员，强烈建议您的测试人员应在报告中，详细说明应用程序版本以及测试环境，通常情况下，应用程序应每两到三周更新一次，例如，我们可能每两周发布一个新版本的应用程序，同时修复老版本错误。

具体来说就是已经完成了2.21版本（假设新版本号），就没有必要在2.01版本（假设旧版本号）创建一个相关漏洞信息的报告。但这里需要注意的是，你需要让你的测试人员详细更新报告，并在报告中指出是哪个应用程序版本出现问题。

根据漏洞类型的不同，测试环境可分为网站版本，操作系统或Web浏览器。例如，你有两个网站www.my-website.com和testing.my-website.com用来测试，但测试环境很显然是不同的（测试服务器和生产服务器），所以导致最终的结果也会不同。因此，测试人员需要在漏洞总结报告中指出详细网址信息。如果发现是运行环境问题，就需要记下浏览器名称和版本。测试人员在报告中需详细描述测试环境，同时可以为后来的网站开发人员节约时间，也可以帮助开发人员了解问题的关键所在。如果测试人员不在报告中添加这一项，那么开发人员也会跳过这一个容易被忽略的地方。他们不负责检测漏洞，并有可能导致任务失败。

漏洞的严重性以及优先级

这两项可以单独列出来，也可以合并为一个参数。而这取决于测试人员使用的漏洞分析平台，漏洞的严重性是针对漏洞对于应用程序的影响，从临界范围（漏洞关键功能）降低（错误很难重现）再到主要功能正常，一些不常用功能很可能出现问题。一般情况下，测试人员会使用这种模式。

漏洞优先级反过来是概述漏洞修复层次结构的工具，项目经理通常设定优先权，漏洞优先级按漏洞严重程度排列，并使得范围逐渐缩小。简单来说，如果一个漏洞关键问题起作用时，那么该漏洞优先级和严重程度都会被评为“高危”漏洞。当然漏洞关键问题并没有那么重要时，我们会指定漏洞的优先级和严重程度，举个例子，在被测试网站登录页面上的一级标题内容出现拼写错误。像这种漏洞危害级别程度很低，而且不影响程序正常功能。网站用户仍然可以登录网站，但我们也不应该忽视这样的漏洞，登录网站的用户第一个看的就是网页内容，所以我们不应该出现这样低级的错误。

在现实中，我们可以在JIRA中指定最初指定的优先级，然后向Web开发人员和项目经理报告漏洞及其优先级或严重程度。项目经理可以联系客户并告诉他们发生了什么事。最后，客户决定是否必须尽快解决这个问题，或选择等待客户的意见可能与测试人员所想的不同，因此这些事项顺序可以根据客户意愿很容易改变。

漏洞描述

测试人员应该向开发人员提供详细的漏洞总结报告（重现漏洞问题）。

重现

这个步骤主要是描述漏洞是如何出现的，当然测试人员越多，越好。

产品

应用程序出现问题的详细描述，测试人员应该提到浏览器、它的版本和运行环境系统状态、用户类型、用户状态、系统初始数据和用户所在的页面。

展示

测试人员展示如何出现漏洞

在看完上文后，我为大家总结一下安全检查列表，主要分为软件安全漏洞、配置错误、产品名称以及影响度量。

实际结果与预期结果

实际结果是当测试人员重现漏洞时发生的事情，质量保证团队提供实际结果的截图，并与预期的结果进行比较。预期的结果是我们在给定条件下预计的正常功能。

下面这两个信息，一个是错误的报告，一个是正确的报告。

正确                                                                                                                          错误

漏洞已经在 Chrome 47以及火狐浏览器（38）测试                                                 打开网站 http://www.hersheys.com

仅在火狐浏览器（38）有效                                                                                     登录

登录https://www.hersheys.com/recipes/en_US/products/baking-pieces.html         退出账户

选择Products选项                                                                                                    选择Reese’s Mini Pieces选项

点击Baking Pieces                                                                                                   实际结果：从列表中删除所选项

                                                                                                                                  预期结果：应打开Reese’s Mini Pieces选项详细说明页

漏洞总结报告的附加信息

这是漏洞总结报告最后的部分，如有必要，测试人员可附上任何相关的附加文件。我们的目标是尽可能多地收集文件，附件可以是，一张截图、一个日志文件（log.txt）、详细描述漏洞文件、测试人员程序接口。在上文已经说明质量保证团队如何写报告，由于某些漏洞分析平台不同细节就会有出入，但遵循这些准则应有助于编写优秀的漏洞总结报告。

本文始发于微信公众号（零组攻防实验室）：如何写好一篇漏洞报告（国外篇）