写好报告

漏洞赏金猎人的工作不仅仅是寻找漏洞；它还向组织的安全团队解释它们。如果您提供一份写得很好的报告，您将帮助与您合作的团队重现漏洞利用，将其分配给适当的内部工程团队，并更快地解决问题。

商业化的报告模板是一个不错的形式，但比它更出色的是，观察与思考。

从工作流程的角度来说，漏洞管理与账面核对也非常重要。一个组织如果长时间接收到报告，那么面临到的问题一定是一些个性化的。比如，漏洞管理过程中，命名的规范直接导致这个能否一眼看出是否重复提交，是否易于管理与记账，是否存在数据之间的关联与匹配性。

文档名称规范化：XXX平台（hackerone）-XXXX编号。
文档名的规范化，保证组织与众测平台之间的唯一性，不会出现这个报告聊成了其他报告。

内容标题规范化：XXX项目或者应用-XXX部门或者元数据-XXX漏洞。
价值性于一份报告在手就能看清所有资产，极大的帮助组织推动报告的分发到负责人手中。

内容标题追加：XXXX编号
方便复制粘贴，不需要再关闭文档，然后右键文档复制编号记账。

您不必中规中矩的模仿任何报告，以下例子是给您一个良好的借鉴，因地制宜的修改自己报告。

第 1 步：制作描述性标题

优秀漏洞报告的第一部分总是一个描述性的标题。目标是用一句话概括问题的标题。理想情况下，它应该允许安全团队立即了解漏洞是什么、发生的位置以及潜在的严重性。为此，它应该回答以下问题：您发现的漏洞是什么？它是否是众所周知的漏洞类型的实例，例如 IDOR 或 XSS？您在目标应用程序中的何处找到它？例如，而不是像“关键端点上的 IDOR”这样的报告标题，使用“https://example.com/change_password 上的 IDOR 导致所有用户的帐户接管”之类的。您的目标是让阅读您的报告的安全工程师对您将在其余部分讨论的内容有一个很好的了解。

漏洞内容标题追加：XSS漏洞，SQL注入，信息泄露或者IDOR等。
漏洞内容的核心价值观在于，组织易于复现与确认。能复现能观察就是说服组织接收最好的方式。
比如：1.目标URL，测试账号 张三/密码 2.点击UI界面的忘记密码 3.bp中发现未授权的API（并截图） 4.重放API发现信息泄露 5.建议：对API做验证和授权。
闭环了兄弟们，这个报告解决了组织从哪里开始复现，观察哪里，危害在哪，行云流水。

第 2 步：提供清晰报告摘要

此部分包含您无法在标题中传达的所有相关详细信息，例如用于攻击的 HTTP 请求参数、您如何找到它等。以下是有效报告摘要的示例：https://example.com/change_password 端点采用两个 POST 正文参数：user_id 和 new_password。对此端点的 POST 请求会将用户 user_id 的密码更改为 new_password。此端点不验证 user_id 参数，因此，任何用户都可以通过操作 user_id 参数来更改其他任何人的密码。一份好的报告摘要是清晰简洁的。它包含了解漏洞所需的所有信息，包括错误是什么、发现错误的位置以及攻击者在被利用时可以做什么。

并非每一个漏洞，组织都能成功的复现，比如IOS，安卓的证书绕过等，它们即有可能在您测试时，使用了一到两个实体机器，并root了一些权限。因此，报告中如果出现复现依赖与环境部署，是您独有的优势之一，为职业化，交互性，商业化，营销化，达不溜化建立了多个良好的发展之路。

漏洞内容的核心价值观在于，组织易于复现与确认。
考虑到组织接收人员的整个大背景，最好从实施开始描述。
比如： 漏洞内容标题：反序列化导致RCE漏洞

关于反序列化的精彩案例可以参考 https://www.freebuf.com/articles/web/290759.html

1.复现依赖：需要自动化利用工具Ysoserial （使用上类似于sqlmap）
需要下载Ysoserial (https://github.com/frohoff/ysoserial/)测试时使用 JRE 11 TLS版本

2.漏洞利用（加截图）
java -jar ysoserial.jar CommonsCollections1 calc.exe

3.修复建议
输入检查
白名单反序列化允许的类
防止篡改序列化 cookie，可以跟踪服务器上的会话状态
使用简单的数据类型，如字符串和数组，能不用序列化就别用
留意补丁并确保依赖项是最新的
owasp反序列化备忘单：https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html

第 3 步：包括严重性评估

您的报告还应包括对错误严重性的诚实评估。除了与您合作修复漏洞之外，安全团队还有其他职责需要处理。包括严重性评估将帮助他们优先修复哪些漏洞，并确保他们立即处理关键漏洞。

比如： 追加标题： 漏洞评级：严重
攻击者可以从外网任何一个地方，利用ysoserial.jar工具发起反序列化RCE攻击。

比如：追加标题： 漏洞评级：低危
攻击者需要配合钓鱼或者xss，才能结合CORS一起实施攻击。

如果您无法给出一个定论：可以参考其他评分组织。

在 https://www.first.org/cvss/ 研究通用漏洞评分系统 (CVSS)，以大致了解每种类型的漏洞的重要性。 CVSS 等级考虑了诸如漏洞如何影响组织、漏洞利用的难度以及漏洞是否需要任何特殊权限或用户交互才能利用等因素。 然后，试着想象一下您的客户公司关心什么，以及哪些漏洞会对业务产生最大的影响。定制您的评估以适应客户的业务优先级。

例如，约会网站可能会发现一个错误，该错误将用户的出生日期暴露为无关紧要，因为用户的年龄已经是网站上的信息，而求职网站可能会发现类似的错误，因为申请人的年龄应该是机密的在求职过程中。另一方面，用户银行信息泄露几乎总是被认为是一个高严重性问题。如果您不确定您的漏洞属于哪个严重等级，请使用漏洞赏金平台的评级量表。例如，Bugcrowd 的评级系统考虑了漏洞的类型和受影响的功能（https://bugcrowd.com/vulnerability-rating-taxonomy/），而 HackerOne 提供了一个基于 CVSS 等级的严重性计算器（https:// docs.hackerone.com/hackers/severity.html）。

第 4 步：给出明确的重现步骤

包括您能想到的所有相关设置先决条件和详细信息。最好假设另一端的工程师不了解该漏洞，也不知道应用程序是如何工作的。例如，一份还可以的报告可能包括以下重现步骤：

1.登录该站点并访问 https://example.com/change_password。
2.单击更改密码按钮。
3.拦截请求，将user_id参数改成另一个用户的ID。

请注意，这些步骤并不全面或明确。他们没有指定您需要两个测试帐户来测试漏洞。他们还假设您对应用程序及其请求格式有足够的了解，无需更多说明即可执行每个步骤。现在，这是来自更好报告的示例：

1.在 example.com 上创建两个帐户：帐户 A 和帐户 B。
2.以A账号登录example.com，访问https://example.com/更改密码。
3.在位于页面左上角的新密码字段中填写所需的新密码。
4.单击位于页面右上角的更改密码按钮。（UI位置截图）
5.拦截发往https://example.com/change_password的POST请求，将user_id POST参数修改为账号B的用户ID。
6.您现在可以使用您选择的新密码登录帐户 B。

尽管安全团队可能仍会理解第一份报告，但第二份报告要具体得多。通过提供许多相关详细信息，您可以避免任何误解并加快缓解过程。这将有助于您所在公司的整体形象与带来更多的业务。

第 5 步：提供概念证明

对于简单的漏洞，您提供的步骤可能就是安全团队重现问题所需的全部步骤。但是对于更复杂的漏洞，包含记录您的漏洞利用的视频、屏幕截图或照片会很有帮助，称为概念验证 (POC) 文件。

例如，对于 CSRF 漏洞，您可以包含一个嵌入了 CSRF 负载的 HTML 文件。这样，安全团队重现问题所需要做的就是在浏览器中打开 HTML 文件。对于 XML 外部实体攻击，包括用于执行攻击的精心制作的 XML 文件。对于需要多个复杂步骤才能重现的漏洞，您可以拍摄您在整个过程中走动的屏幕截图视频。像这样的 POC 文件可以节省安全团队的时间，因为他们不必自己准备攻击负载。您还可以包含用于攻击应用程序的任何精心制作的 URL、脚本或上传文件。

你的屏幕截图视频，可以推动整个行业的发展，让组织与平台一看，对。我们需要这样的功能性。

第 6 步：描述影响和攻击场景

为了帮助安全团队充分了解漏洞的潜在影响，您还可以说明漏洞可能被利用的合理场景。请注意，此部分与我之前提到的严重性评估不同。严重性评估描述了攻击者利用漏洞的后果的严重性，而攻击场景则解释了这些后果的实际情况。

以下是影响部分的示例：
使用此漏洞，攻击者更改用户密码所需的只是他们的 user_id。由于每个用户的公开个人资料页面都列出了帐户的 user_id，因此任何人都可以访问任何用户的个人资料，找到他们的 user_id 并更改他们的密码。而且因为 user_ids 只是序列号，黑客甚至可以枚举所有 user_ids 并更改所有用户的密码！这个漏洞可以让攻击者以最小的努力接管任何人的帐户。

一个好的影响部分说明了攻击者如何实际利用漏洞。它考虑了任何缓解因素以及可以实现的最大影响。它永远不应该夸大错误的影响或包含任何假设。

第 7 步：推荐可能的缓解措施

您还可以推荐安全团队采取的缓解漏洞的可能步骤。这将节省团队开始研究缓解措施的时间。通常，由于您是发现该漏洞的安全研究人员，您将熟悉该应用程序功能的特定行为，因此可以很好地提出全面修复。

但是，除非您对问题的根本原因有很好的了解，否则不要提出修复建议。内部团队可能有更多的背景和专业知识来提供适用于其环境的适当缓解策略。如果您不确定导致漏洞的原因或可能的修复方法，请避免提供任何建议，以免混淆读者。

您可以提出以下可能的缓解措施：
应用程序应在更改密码请求中验证用户的 user_id 参数，以确保用户有权进行帐户修改。应用程序应拒绝并记录未经授权的请求。

您不必深入了解修复的技术细节，因为您不了解应用程序的底层代码库。但作为了解漏洞类别的人，您可以提供缓解方向。

步骤 8：验证报告

最后，始终验证您的报告。最后一次检查您的报告，以确保没有技术错误或任何可能阻止安全团队理解它的内容。遵循您自己的重现步骤以确保它们包含足够的详细信息。检查所有 POC 文件和代码以确保它们正常工作。通过验证您的报告，您可以最大限度地减少提交无效报告的可能性。

报告写得越多，所花费的时间越久，但因为价值性大，可以适度加钱。贵一点不是问题，问题是花得值不值，时间投入得值不值。

编写精彩报告的其他提示

以下是帮助您尽可能提供最佳报告的其他提示。

不要假设任何事情

请记住，我们不是犯罪，有时候给不出完美的攻击链。适度的假设或者引经论点不是不行。如果不想假设，尽量引用已经发生的案件或者行业内的共识。而不是让自己犯罪。

首先，不要假设安全团队能够理解您报告中的所有内容。请记住，您可能已经使用此漏洞一周了，但对于收到报告的安全团队来说，这是全新的信息。他们肩负着许多其他职责，而且通常不像您那样熟悉该功能。此外，报告并不总是分配给安全团队。较新的程序、开源项目和初创公司可能依赖开发人员或技术支持人员来处理错误报告，而不是拥有专门的安全团队。帮助他们了解您的发现。

尽可能详细，并包括您能想到的所有相关细节。包含指向解释安全团队可能不熟悉的晦涩安全知识的参考文献的链接也很好。想想冗长的潜在后果与遗漏基本细节的后果。如果您过于冗长，最糟糕的情况是您的报告需要多花两分钟的时间来阅读。但如果您遗漏了重要的细节，漏洞的修复可能会延迟，恶意黑客可能会利用该漏洞。

简洁明了

另一方面，不要包含任何不必要的信息，例如冗长的问候、笑话或模因。安全报告是商业文件，而不是给您朋友的信。它应该是直截了当的。在不遗漏关键细节的情况下，使您的报告尽可能简短。您应该始终努力节省安全团队的时间，以便他们可以立即修复漏洞。

写你想读的

在写作时始终把你的读者放在心上，并努力为他们建立良好的阅读体验。用对话的语气写作，不要使用利兹语、俚语或缩写。这些会使文本更难阅读，并会增加读者的烦恼。

专业

最后，始终以尊重和专业的态度与安全团队沟通。耐心、及时地提供有关报告的说明。

您在撰写报告时可能会犯错误，并且不可避免地会发生误传。但请记住，作为安全研究人员，您有能力通过在写作中投入时间和精力来最大限度地减少这种可能性。通过磨练你的报告技巧和你的黑客技能，你可以节省每个人的时间并最大化你作为黑客的价值。

与开发团队建立关系

您作为黑客的工作不会在您提交报告的那一刻停止。作为发现漏洞的人，您应该帮助公司修复问题并确保漏洞已完全修补。

与安全团队建立牢固的关系将有助于更快、更顺利地解决您的报告。如果您能够始终如一地为组织的安全做出贡献，它甚至可能会导致更大的错误赏金支出。一些漏洞赏金猎人甚至因为他们的漏洞赏金结果而获得了顶级科技公司的面试或工作机会！我们将讨论您报告的不同状态、在缓解过程的每个阶段您应该做什么，以及在与安全团队沟通时如何处理冲突。

您不必在乎目前在哪，什么公司，岗位，证书，学历等问题。一直与组织建立关系，终有一天可以突围。

了解报告状态

提交报告后，安全团队会将其归类为报告状态，该状态描述了报告的当前状态。随着缓解过程的推进，报告状态将发生变化。您可以在漏洞赏金平台的界面上或从安全团队收到的消息中找到列出的报告状态。

在组织内部的SDLC平台里也有类似的漏洞管理状态。

需要更多信息

您将看到的最常见的报告状态之一是需要更多信息。这意味着安全团队没有完全理解您的报告，或者无法使用您提供的信息重现问题。安全团队通常会跟进有关漏洞的其他信息的问题或请求。

在这种情况下，您应该修改您的报告，提供任何缺失的信息，并解决安全团队的其他问题。

开发人员在修复时是真的找不到某个参数在哪里，一时半会儿无法定位到位置。会提起OA流程，让您提供其他缺失的信息。

信息量大

如果安全团队将您的报告标记为信息丰富，他们将不会修复错误。这意味着他们认为您报告的问题是一个安全问题，但不足以保证修复。不影响其他用户的漏洞，例如在网络游戏中提高自己分数的能力，通常属于这一类。另一种通常标记为信息性的错误是缺少安全最佳实践，例如允许用户重复使用密码。

报告没有接收可能性其实非常多：比如难于修复，难于理解，难于复现，组织人员流动性，历史遗留，测试环境与真实环境的差异性等。

在这种情况下，您对报告无能为力！公司不会给你赏金，你也不必跟进，除非你认为安全团队犯了错误。但是，我确实建议您跟踪信息丰富的问题，并尝试将它们链接成更大、更有影响力的错误。

重复提交

重复报告状态意味着另一个黑客已经发现了该漏洞，并且公司正在修复漏洞。不幸的是，由于公司仅将漏洞奖励奖励给第一个发现漏洞的黑客，因此您不会因重复而获得报酬.除了帮助公司解决问题外，报告与此无关。您还可以尝试将错误升级或链接为更具影响力的错误。这样，安全团队可能会将新报告视为一个单独的问题并奖励您。

N/A

不适用 (N/A) 状态意味着您的报告不包含具有安全影响的有效安全问题。当您的报告包含技术错误或错误是有意的应用程序行为时，可能会发生这种情况。

N/A 报告不付款。除了继续前进并继续黑客攻击之外，您没有什么可做的！

不要沮丧：每个人都需要成长，您可以购买专业书籍已观察别人的知识和方法。

漏洞管理与分类

安全团队在最终验证报告后对报告进行分类。这对您来说是个好消息，因为这通常意味着安全团队将修复错误并奖励您。

对报告进行分类后，您应该帮助安全团队解决问题。及时跟进他们的问题，并提供他们要求的任何其他信息。

解决

当您的报告被标记为已解决时，报告的漏洞已被修复。在这一点上，拍拍自己的后背，为您让互联网变得更安全而感到高兴。如果您正在参与付费漏洞赏金计划，您也可以在此时收到付款！

除了庆祝和继续黑客攻击之外，与报告没有任何关系。

处理冲突

并非所有报告都能快速顺利地得到解决。当黑客和安全团队在错误的有效性、错误的严重性或适当的支付金额上存在分歧时，冲突不可避免地发生。即便如此，冲突可能会破坏您作为黑客的声誉，因此专业地处理它们是成功寻找漏洞的关键。如果您发现自己与安全团队发生冲突，您应该这样做。

当您与安全团队不同意错误的有效性时，首先要确保您的初始报告中的所有信息都是正确的。通常，由于技术或写作错误，安全团队将报告标记为信息性或 N/A。例如，如果您在 POC 中包含不正确的 URL，安全团队可能无法重现该问题。如果这导致了分歧，请尽快发送包含正确信息的后续报告。

另一方面，如果您没有在报告中犯错，但仍然认为他们错误地标记了问题，请发送后续邮件，解释您认为该错误是安全问题的原因。如果仍然不能解决误解，您可以请求漏洞赏金平台或团队中的其他安全工程师进行调解。

大多数情况下，如果漏洞不属于众所周知的错误类别，其他人很难看到它的影响。如果安全团队不理会所报告问题的严重性，您应该解释一些潜在的攻击场景，以充分说明其影响。

最后，如果您对赏金金额不满意，请不要怨恨地进行交流。询问组织分配赏金的理由，并解释为什么你认为你应该得到更高的奖励。例如，如果你报告的负责人低估了 bug 的严重性，你可以在要求更高的奖励时详细说明问题的影响。无论你做什么，总是避免在没有解释的情况下索要更多的钱。

钱不是问题，合理的理由与解释不能少，确保充分的沟通。

记住，我们都会犯错。如果您认为处理您报告的人处理不当，请礼貌地要求重新考虑。一旦你提出你的理由之后，请尊重公司关于修复和赏金金额的最终决定。

建立伙伴关系

解决报告后，漏洞赏金之旅不会停止。您应该努力与组织建立长期合作伙伴关系。这可以帮助您更顺利地解决您的报告，甚至可能会让您获得面试或工作机会。您可以通过尊重他们的时间并以专业精神进行沟通来与公司建立良好的关系。

首先，通过始终提交经过验证的报告来获得尊重。不要通过发送垃圾邮件、缠着他们索取金钱或口头辱骂安全团队来破坏公司的信任。反过来，他们会尊重你并优先考虑你作为研究人员。公司经常禁止不尊重或不讲道理的猎人，因此不惜一切代价避免落入这些类别。

还要了解与您合作的每个组织的沟通方式。他们期望报告中有多少细节？您可以通过阅读他们公开披露的报告，或将他们对您的报告的反馈纳入未来的消息中，了解安全团队的沟通方式。他们是否希望有大量照片和视频来记录错误？自定义您的报告，让读者的工作更轻松。

它们可能在未来孵化出更多的商业化产品

最后，确保您支持安全团队，直到他们解决问题。许多组织会在报告分类时向您支付赏金，但请不要在收到奖励后对安全团队进行保释！如果需要，请提供建议以帮助缓解漏洞，并帮助安全团队确认问题已得到修复。有时，组织会要求您进行收费的重新测试。如果可以，请务必抓住这个机会。您不仅可以赚钱，还可以帮助公司更快地解决问题。