Question

A bug bounty hunter’s job isn’t just finding vulnerabilities; it’s also explaining them to the organization’s security team. If you provide a well-written report, you’ll help the team you’re working with reproduce the exploit, assign it to the appropriate internal engineering team, and fix the issue faster. The faster a vulnerability is fixed, the less likely malicious hackers are to exploit it. In this section, I’ll break down the components of a good vulnerability report and introduce some tips and tricks I’ve learned along the way.

一个漏洞赏金猎人的工作不仅是寻找漏洞，而且还需要向组织的安全团队解释它们。如果您提供一个写得很好的报告，您将帮助您正在与之合作的团队重现漏洞、将其分配给适当的内部工程团队并更快地修复问题。漏洞被解决得越快，恶意黑客利用漏洞的可能性就越小。在本节中，我将分解一个好的漏洞报告的组成部分，并介绍我学到的一些技巧和诀窍。

Step 1: Craft a Descriptive Title

The first part of a great vulnerability report is always a descriptive title. Aim for a title that sums up the issue in one sentence. Ideally, it should allow the security team to immediately get an idea of what the vulnerability is, where it occurred, and its potential severity. To do so, it should answer the following questions: What is the vulnerability you’ve found? Is it an instance of a well-known vulnerability type, such as IDOR or XSS? Where did you find it on the target application?

一份良好的漏洞报告的第一部分总是一个描述性的标题。标题应该简洁概括问题，并尽可能的让安全团队立刻明确漏洞所在，其影响和潜在程度。为了做到这一点，它应该回答以下问题：你发现的漏洞是什么？它是否属于 IDOR 或 XSS 等已知漏洞类型？在目标应用程序的哪里发现它？

For example, instead of a report title like “IDOR on a Critical Endpoint,” use one like “IDOR on https://example.com/change_password Leads to Account Takeover for All Users.” Your goal is to give the security engineer reading your report a good idea of the content you’ll discuss in the rest of it.

例如，可以使用“https://example.com/change_password 上的 IDOR 导致所有用户的账户接管”这样的报告标题，而非“关键端点上的 IDOR”。您的目标是让阅读报告的安全工程师对您接下来要讨论的内容有一个良好的了解。

Step 2: Provide a Clear Summary

Next, provide a report summary. This section includes all the relevant details you weren’t able to communicate in the title, like the HTTP request parameters used for the attack, how you found it, and so on.

接下来，提供报告摘要。此部分包括所有相关的细节，您在标题中无法传达，比如用于攻击的 HTTP 请求参数，您是如何发现它的等等。

Here’s an example of an effective report summary:

以下是一份有效报告摘要的例子：

The https://example.com/change_password endpoint takes two POST body parameters: user_id and new_password . A POST request to this endpoint would change the password of user user_id to new_password . This endpoint is not validating the user_id parameter, and as a result, any user can change anyone else’s password by manipulating the user_id parameter.

https://example.com/change_password 端点需要两个 POST 请求体参数：user_id 和 new_password。对此端点的 POST 请求将把用户 user_id 的密码更改为 new_password。此端点未验证 user_id 参数，因此任何用户都可以通过操作 user_id 参数来更改其他任何人的密码。

A good report summary is clear and concise. It contains all the information needed to understand a vulnerability, including what the bug is, where the bug is found, and what an attacker can do when it’s exploited.

一个好的报告摘要应该清晰简明。它包含了理解某个漏洞所需的所有信息：包括 bug 是什么，它在哪里被发现，以及攻击者在利用该漏洞时会做些什么。

Step 3: Include a Severity Assessment

Your report should also include an honest assessment of the bug’s severity. In addition to working with you to fix vulnerabilities, security teams have other responsibilities to tend to. Including a severity assessment will help them prioritize which vulnerabilities to fix first, and ensure that they take care of critical vulnerabilities right away.

你的报告还应包括漏洞的严重程度诚恳的评估。除了与你合作修复漏洞外，安全团队还有其他职责需要注意。包括漏洞严重性评估将有助于他们优先处理哪些漏洞，并确保立即处理重要漏洞。

You could use the following scale to communicate severity:

您可以使用以下标尺来沟通严重程度：

Low severity

低严重性

The bug doesn’t have the potential to cause a lot of damage. For example, an open redirect that can be used only for phishing is a low-severity bug.

这个漏洞没有潜在的能力造成很大的损害。例如，只能用于网络钓鱼的开放重定向是低严重性漏洞。

Medium severity

中等严重性

The bug impacts users or the organization in a moderate way, or is a high-severity issue that’s difficult for a malicious hacker to exploit. The security team should focus on high- and critical-severity bugs first. For example, a cross-site request forgery (CSRF) on a sensitive action such as password change is often considered a medium-severity issue.

漏洞对用户或组织的影响较为中等，或者是一个高严重性问题，不易被恶意黑客利用。安全团队应该首先关注高和严重的漏洞。例如，对于敏感操作（如密码更改）的跨站点请求伪造（CSRF）通常被视为中等严重性问题。

High severity

高严重性

The bug impacts a large number of users, and its consequences can be disastrous for these users. The security team should fix a high-security bug as soon as possible. For example, an open redirect that can be used to steal OAuth tokens is a high-severity bug.

该漏洞影响大量用户，其后果可能对这些用户造成灾难性的影响。安全团队应该尽快修复高安全性漏洞。例如，一个可用于窃取 OAuth 令牌的开放重定向是一种高危漏洞。

Critical severity

重要性严重

The bug impacts a majority of the user base or endangers the organization’s core infrastructure. The security team should fix a critical-severity bug right away. For example, a SQL injection leading to remote code execution (RCE) on the production server will be considered a critical issue.

Bug 影响到大多数用户或危及组织的核心基础设施。安全团队应立即修复关键性缺陷。例如，在生产服务器上导致远程代码执行（RCE）的 SQL 注入将被视为关键问题。

Study the Common Vulnerability Scoring System ( CVSS ) at https://www.first.org/cvss/ for a general idea of how critical each type of vulnerability is. The CVSS scale takes into account factors such as how a vulnerability impacts an organization, how hard the vulnerability is to exploit, and whether the vulnerability requires any special privileges or user interaction to exploit.

学习通用漏洞评分系统（CVSS）https://www.first.org/cvss/ 以了解每种漏洞的严重程度。CVSS 评分考虑了漏洞对组织的影响、漏洞的利用难度以及漏洞是否需要特殊权限或用户交互才能利用等因素。

Then, try to imagine what your client company cares about, and which vulnerabilities would present the biggest business impact. Customize your assessment to fit the client’s business priorities. For example, a dating site might find a bug that exposes a user’s birth date as inconsequential, since a user’s age is already public information on the site, while a job search site might find a similar bug significant, because an applicant’s age should be confidential in the job search process. On the other hand, leaks of users’ banking information are almost always considered a high-severity issue.

那么，试着想象一下你的客户公司关心什么，以及哪些漏洞可能会对业务产生最大的影响。将您的评估定制以适应客户的业务优先级。例如，约会网站可能会发现暴露用户出生日期的漏洞并不重要，因为用户的年龄已经是公共信息，而求职网站可能会发现类似的漏洞非常重要，因为申请人的年龄应该在求职过程中保密。另一方面，用户银行信息的泄露几乎总是被认为是高度严重的问题。

If you’re unsure which severity rating your bug falls into, use the rating scale of a bug bounty platform. For example, Bugcrowd’s rating system takes into account the type of vulnerability and the affected functionality ( https://bugcrowd.com/vulnerability-rating-taxonomy/ ), and HackerOne provides a severity calculator based on the CVSS scale ( https://docs.hackerone.com/hackers/severity.html ).

如果您不确定您的漏洞属于哪个严重级别，请使用漏洞赏金平台的评级标准。例如，Bugcrowd 的评估系统考虑到漏洞类型和受影响的功能（https://bugcrowd.com/vulnerability-rating-taxonomy/），而 HackerOne 则基于 CVSS 标准提供了一个严重性计算器（https://docs.hackerone.com/hackers/severity.html）。

You could list the severity in a single line, as follows:

你可以将严重程度列在单行中，如下所示：

Severity of the issue: High

问题的严重程度：高

Providing an accurate assessment of severity will make everyone’s lives easier and contribute to a positive relationship between you and the security team.

提供准确的严重性评估将使每个人的生活更容易，并促进您与安全团队之间的积极关系。

Step 4: Give Clear Steps to Reproduce

Next, provide step-by-step instructions for reproducing the vulnerability. Include all relevant setup prerequisites and details you can think of. It’s best to assume the engineer on the other side has no knowledge of the vulnerability and doesn’t know how the application works.

请提供重现漏洞的逐步说明。包括所有相关的设置前提条件和您可以想到的细节。最好假设另一边的工程师不知道漏洞，也不知道应用程序如何工作。

For example, a merely okay report might include the following steps to reproduce:

例如，一个仅仅还可以的报告可能包括以下重现步骤：

1. Log in to the site and visit https://example.com/change_password .
2. Click the Change Password button.
3. Intercept the request, and change the user_id parameter to another user’s ID.

Notice that these steps aren’t comprehensive or explicit. They don’t specify that you need two test accounts to test for the vulnerability. They also assume that you have enough knowledge about the application and the format of its requests to carry out each step without more instructions.

请注意，这些步骤不是全面或明确的。它们没有说明你需要两个测试帐户来测试漏洞。它们还假定你已经具有足够的关于应用程序和其请求格式的知识，可以在没有更多指示的情况下执行每个步骤。

Now, here is an example from a better report:

现在，这里有一个来自更好的报告的例子：

1. Make two accounts on example.com : account A and account B.
2. Log in to example.com as account A, and visit https://example.com/change_password .
3. Fill in the desired new password in the New password field, located at the top left of the page.
4. Click the Change Password button located at the top right of the page.
5. Intercept the POST request to https://example.com/change_password and change the user_id POST parameter to the user ID of account B.
6. You can now log in to account B by using the new password you’ve chosen.

Although the security team will probably still understand the first report, the second report is a lot more specific. By providing many relevant details, you can avoid any misunderstanding and speed up the mitigation process.

虽然安全团队可能仍然能够理解第一个报告，但第二个报告更加具体。提供许多相关细节，可以避免任何误解并加快缓解过程。

Step 5: Provide a Proof of Concept

For simple vulnerabilities, the steps you provide might be all that the security team needs to reproduce the issue. But for more complex vulnerabilities, it’s helpful to include a video, screenshots, or photos documenting your exploit, called a proof-of-concept ( POC ) file.

对于简单漏洞来说，您提供的步骤可能就足够让安全团队能够再现这个问题了。但对于更复杂的漏洞而言，包含一段视频、屏幕截图或照片来记录你的攻击过程便有助于我们理解，这些被称作概念证明（Proof-of-concept, POC）文件。

For example, for a CSRF vulnerability, you could include an HTML file with the CSRF payload embedded. This way, all the security team needs to do to reproduce the issue is to open the HTML file in their browser. For an XML external entity attack, include the crafted XML file that you used to execute the attack. And for vulnerabilities that require multiple complicated steps to reproduce, you could film a screen-capture video of you walking through the process.

例如，针对 CSRF 漏洞，您可以包含一个带有嵌入的 CSRF 负载的 HTML 文件。这样，安全团队只需要在浏览器中打开 HTML 文件即可复现问题。对于 XML 外部实体攻击，包含您用于执行攻击的精心制作的 XML 文件。对于需要多个复杂步骤才能重现的漏洞，您可以拍摄屏幕录像，让观众跟着您的步骤。

POC files like these save the security team time because they won’t have to prepare the attack payload themselves. You can also include any crafted URLs, scripts, or upload files you used to attack the application.

这些 POC 文件将为安全团队节省时间，因为他们无需自己准备攻击载荷。您还可以包括任何定制的 URL、脚本或上传文件，用于攻击应用程序。

Step 6: Describe the Impact and Attack Scenarios

To help the security team fully understand the potential impact of the vulnerability, you can also illustrate a plausible scenario in which the vulnerability could be exploited. Note that this section is not the same as the severity assessment I mentioned earlier. The severity assessment describes the severity of the consequences of an attacker exploiting the vulnerability, whereas the attack scenario explains what those consequences would actually look like.

为了帮助安全团队充分了解漏洞可能产生的影响，您还可以举出漏洞可能被利用的合理场景。请注意，这一部分与之前提到的严重性评估不同。严重性评估描述的是攻击者利用漏洞所造成后果的严重程度，而攻击场景则解释了这些后果实际上会是什么样的。

If hackers exploited this bug, could they take over user accounts? Or could they steal user information and cause large-scale data leaks? Put yourself in a malicious hacker’s shoes and try to escalate the impact of the vulnerability as much as possible. Give the client company a realistic sense of the worst-case scenario. This will help the company prioritize the fix internally and determine if any additional steps or internal investigations are necessary.

如果黑客利用了这个漏洞，他们能够接管用户帐户吗？或者他们能够窃取用户信息并造成大规模的数据泄露吗？请将自己置身于一个恶意黑客的角度，并尝试最大限度地升级漏洞的影响。给客户公司一个最坏情况的现实感。这将有助于公司确定内部优先修复，并确定是否需要任何额外的步骤或内部调查。

Here is an example of an impact section:

以下是一个影响部分的示例：

Using this vulnerability, all that an attacker needs in order to change a user’s password is their user_id . Since each user’s public profile page lists the account’s user_id , anyone can visit any user’s profile, find out their user_id , and change their password. And because user_id s are simply sequential numbers, a hacker can even enumerate all the user_id s and change the passwords of all users! This bug will let attackers take over anyone’s account with minimal effort.

利用这个漏洞，攻击者只需要知道用户的 user_id 就能够更改他们的密码。由于每个用户的公共个人资料页面都列出了帐户的 user_id，任何人都可以访问任何用户的个人资料页面，找到他们的 user_id 并修改他们的密码。而且，由于 user_id 仅仅是顺序数字，黑客甚至可以枚举所有的 user_id 并更改所有用户的密码！这个漏洞会让攻击者用最小的努力就能接管任何人的帐户。

A good impact section illustrates how an attacker can realistically exploit a bug. It takes into account any mitigating factors as well as the maximum impact that can be achieved. It should never overstate a bug’s impact or include any hypotheticals.

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

Step 7: Recommend Possible Mitigations

You can also recommend possible steps the security team can take to mitigate the vulnerability. This will save the team time when it begins researching mitigations. Often, since you’re the security researcher who discovered the vulnerability, you’ll be familiar with the particular behavior of that application feature, and thus in a good position to come up with a comprehensive fix.

您也可以向安全团队推荐可能采取的措施来减轻其漏洞。当安全团队开始研究减轻措施时，这将节省时间。通常，作为发现漏洞的安全研究员，您将熟悉该应用程序功能的特定行为，因此处于提出综合解决方案的良好位置。

However, don’t propose fixes unless you have a good understanding of the root cause of the issue. Internal teams may have much more context and expertise to provide appropriate mitigation strategies applicable to their environment. If you’re not sure what caused the vulnerability or what a possible fix might be, avoid giving any recommendations so you don’t confuse your reader.

但是，除非你对问题的根本原因有很好的理解，否则不要提出修复建议。内部团队可能拥有更多的背景和专业知识，可以提供适用于他们的环境的适当减轻策略。如果你不确定漏洞的原因或可能的修复方法，最好不要提供任何建议，这样你就不会让你的读者感到困惑。

Here is a possible mitigation you could propose:

这里是你可以提出的可能的缓解措施：

The application should validate the user’s user_id parameter within the change password request to ensure that the user is authorized to make account modifications. Unauthorized requests should be rejected and logged by the application.

应用程序应在更改密码请求中验证用户的 user_id 参数，以确保用户有权进行帐户修改。未经授权的请求应被拒绝并由应用程序记录。

You don’t have to go into the technical details of the fix, since you don’t have knowledge of the application’s underlying codebase. But as someone who understands the vulnerability class, you can provide a direction for mitigation.

作为一个理解漏洞类别的人，你无需深入修复的技术细节，因为你并不了解应用程序底层代码。但是，你可以为缓解提供一个方向。

Step 8: Validate the Report

Finally, always validate your report. Go through your report one last time to make sure that there are no technical errors, or anything that might prevent the security team from understanding it. Follow your own Steps to Reproduce to ensure that they contain enough details. Examine all of your POC files and code to make sure they work. By validating your reports, you can minimize the possibility of submitting an invalid report.

最后，一定要验证您的报告。仔细检查一遍您的报告，确保没有技术错误或任何可能阻止安全团队理解的内容。按照您自己的重现步骤确保其包含足够的细节。检查所有的 POC 文件和代码以确保其可用。通过验证您的报告，您可以最大程度地减少提交无效报告的可能性。

Additional Tips for Writing Better Reports

Here are additional tips to help you deliver the best reports possible.

以下是一些建议，帮助您提供最佳报告。

Don’t Assume Anything

First, don’t assume that the security team will be able to understand everything in your report. Remember that you might have been working with this vulnerability for a week, but to the security team receiving the report, it’s all new information. They have a whole host of other responsibilities on their plates and often aren’t as familiar with the feature as you. Additionally, reports are not always assigned to security teams. Newer programs, open source projects, and startups may depend on developers or technical support personnel to handle bug reports instead of having a dedicated security team. Help them understand what you’ve discovered.

首先，不要假定安全团队能够理解您报告中的所有内容。请记住，您可能已经研究这个漏洞一周了，但对于接收报告的安全团队而言，这都是新信息。他们可能有很多其他的责任，并且通常不像你那么熟悉这个功能。此外，报告并不总是分配给安全团队。新的程序、开源项目和创业公司可能依赖开发人员或技术支持人员来处理漏洞报告，而不是有专门的安全团队。帮助他们理解您发现了什么。

Be as verbose as possible, and include all the relevant details you can think of. It’s also good to include links to references explaining obscure security knowledge that the security team might not be familiar with. Think about the potential consequences of being verbose versus the consequences of leaving out essential details. The worst thing that can happen if you’re too wordy is that your report will take two extra minutes to read. But if you leave out important details, the remediation of the vulnerability might get delayed, and a malicious hacker might exploit the bug.

尽可能详细地描述，包括所有相关细节。最好还要提供链接，以便解释安全团队可能不熟悉的晦涩安全知识。请考虑冗长报告的潜在后果和省略关键细节的后果。过分详细的最坏结果就是你的报告需要多花两分钟来阅读。但是如果你遗漏了重要细节，漏洞的修复工作可能会延迟，造成恶意黑客利用漏洞的后果。

Be Clear and Concise

On the other hand, don’t include any unnecessary information, such as wordy greetings, jokes, or memes. A security report is a business document, not a letter to your friend. It should be straightforward and to the point. Make your report as short as possible without omitting the key details. You should always be trying to save the security team’s time so they can get to remediating the vulnerability right away.

另一方面，不要包含任何不必要的信息，比如冗长的问候、笑话或表情包。一份安全报告是一份业务文件，而不是给朋友的信。它应该简单明了，直截了当。在不遗漏关键细节的情况下，尽量让报告尽可能简短。你应该一直在努力节省安全团队的时间，这样他们就可以立即开始修复漏洞。

Write What You Want to Read

Always put your reader in mind when writing, and try to build a good reading experience for them. Write in a conversational tone and don’t use leetspeak, slang, or abbreviations. These make the text harder to read and will add to your reader’s annoyance.

写作时要时刻考虑读者，尝试为他们创造良好的阅读体验。使用谈话式的语气，不要使用网络语言、俚语或缩写。这些会让文章更难读，会让读者更加恼怒。

Be Professional

Finally, always communicate with the security team with respect and professionalism. Provide clarifications regarding the report patiently and promptly.

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

You’ll probably make mistakes when writing reports, and miscommunication will inevitably happen. But remember that as the security researcher, you have the power to minimize that possibility by putting time and care into your writing. By honing your reporting skills in addition to your hacking skills, you can save everyone’s time and maximize your value as a hacker.

写报告时可能会犯错，不可避免地会有误传情况发生。但要记住，作为安全研究人员，通过投入时间和精力来撰写报告，您有能力最小化这种可能性。通过磨练报告技巧和黑客技能，您可以为大家节省时间，最大化您作为黑客的价值。