How to write a report

Time:2022-5-8
How to write a report

u=203448570,1335589887&fm=26&fmt=auto.jpeg

Write a report

Loophole bounty hunters do more than just look for loopholes; It also explains them to the organization’s security team. If you provide a well written report, you will help the team you work with reproduce the exploit, assign it to the appropriate internal engineering team, and solve the problem faster.

The commercial report template is a good form, but what is better than it is observation and thinking.

From the perspective of workflow, vulnerability management and Book reconciliation are also very important. If an organization receives reports for a long time, the problems it faces must be personalized. For example, in the process of vulnerability management, the specification of naming directly leads to whether it can see at a glance whether there is repeated submission, whether it is easy to manage and keep accounts, and whether there is correlation and matching between data.

Document name Standardization: XXX platform (hackerone) – XXXX number.
The standardization of the document name ensures the uniqueness between the organization and the public testing platform. This report will not appear and become other reports.

Content Title Standardization: XXX project or application – XXX department or metadata – XXX vulnerability.
The value lies in the fact that all assets can be seen in one report, which greatly helps the organization to promote the distribution of the report to the person in charge.

Content title: XXXX number added
It is convenient to copy and paste. There is no need to close the document, and then right-click the document copy number for bookkeeping.

You don’t have to imitate any report in a regular way. The following example is a good reference for you to modify your report according to local conditions.

[technical learning]

Step 1: create a descriptive title

The first part of a good vulnerability report is always a descriptive title. The goal is to summarize the title of the problem in one sentence. Ideally, it should allow the security team to immediately understand what vulnerabilities are, where they occur, and the potential severity. To this end, it should answer the following questions: what are the vulnerabilities you found? Is it an instance of a well-known vulnerability type, such as idor or XSS? Where did you find it in the target application? For example, instead of a report title like “idor on critical endpoint”, use“https://example.com/change_passwordIdor on causes all users’ accounts to take over “and so on. Your goal is to give the safety engineer reading your report a good understanding of what you will discuss in the rest of the section.

The title of vulnerability content added: XSS vulnerability, SQL injection, information disclosure or idor, etc.
The core value of vulnerability content is that the organization is easy to reproduce and confirm. Being able to reproduce and observe is the best way to persuade the organization to accept.
For example: 1 Target URL, test account Zhang San / password 2 Click forget password 3 on the UI interface Unauthorized API found in BP (and screenshot) 4 Information leakage found in replay API 5 Suggestion: verify and authorize the API.
Closed loop, brothers, this report solves the problem of where the organization starts to reappear, where to observe and where the harm is.

Step 2: provide a clear summary of the report

This section contains all relevant details that you cannot convey in the title, such as the HTTP request parameters used for the attack, how you find it, and so on. The following is an example of a valid report summary:https://example.com/change_passwordThe endpoint adopts two post body parameters: user_ ID and new_ password。 A post request to this endpoint will send the user user_ The password for ID is changed to new_ password。 This endpoint does not validate user_ ID parameter, so any user can operate user_ ID parameter to change anyone else’s password. A good report summary is clear and concise. It contains all the information needed to understand the vulnerability, including what the error is, where the error is found, and what an attacker can do if exploited.

Not every vulnerability can be successfully replicated by the organization, such as IOS, Android certificate bypass, etc. they may use one or two entity machines and have some permissions when you test. Therefore, if there is recurrence dependence and environmental deployment in the report, it is one of your unique advantages. It has established many good development paths for professionalization, interactivity, commercialization, marketing and Tatsu.

The core value of vulnerability content is that the organization is easy to reproduce and confirm.
Considering the overall background of the receiving personnel of the organization, it is best to start from the implementation.
For example: vulnerability content title: deserialization leads to rce vulnerability

1. Recurrence dependency: need to use the tool ysoserial automatically (similar to sqlmap in use)
Need to download ysoserial(https://github.com/frohoff/ysoserial/)The JRE 11 TLS version was used for testing

2. Exploit (add screenshot)
java -jar ysoserial.jar CommonsCollections1 calc.exe

3. Repair suggestions
Input check
Whitelist deserialization allowed classes
Prevent tampering with serialized cookies, which can track the session state on the server
Use simple data types, such as strings and arrays, and don’t use them without serialization
Watch for patches and make sure dependencies are up to date
Osasp deserialization memo:https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html

How to write a report

Insert picture description here

Step 3: include severity assessment

Your report should also include an honest assessment of the severity of the error. In addition to working with you to fix vulnerabilities, the security team has other responsibilities to deal with. Including a severity assessment will help them prioritize which vulnerabilities to fix and ensure that they address critical vulnerabilities immediately.

For example: add Title: vulnerability rating: serious
Attackers can use ysoserial from anywhere on the Internet The jar tool initiates a deserialization rce attack.

For example: add the title: vulnerability rating: low risk
Attackers need to cooperate with fishing or XSS to attack together with CORS.

If you can’t give a conclusion: you can refer to other scoring organizations.

stayhttps://www.first.org/cvss/Study the general vulnerability scoring system (CVss) to roughly understand the importance of each type of vulnerability. CVss level considers factors such as how vulnerabilities affect the organization, the difficulty of vulnerability exploitation, and whether vulnerabilities need any special permissions or user interaction to be exploited. Then, try to imagine what your client company cares about and which vulnerabilities will have the greatest impact on the business. Customize your assessment to fit your customer’s business priorities.

For example, a dating website may find an error that exposes the user’s date of birth as irrelevant because the user’s age is already information on the website, while a job search website may find a similar error because the applicant’s age should be confidential during the job search process. On the other hand, user bank information disclosure is almost always considered to be a high severity problem. If you are not sure which severity level your vulnerability belongs to, please use the rating scale of vulnerability reward platform. For example, bugcrowd’s rating system considers the types of vulnerabilities and affected functions(https://bugcrowd.com/vulnerability-rating-taxonomy/)Hackerone provides a severity calculator based on CVss level (HTTPS://docs.hackerone.com/hackers/severity.html)。

Step 4: give clear reproduction steps

Include all relevant setup prerequisites and details you can think of. It’s best to assume that the Engineer at the other end doesn’t understand the vulnerability or how the application works. For example, a good report may include the following reproduction steps:

1. Log in to the site and visithttps://example.com/change_password
2. Click the change password button.
3. Intercept the request and send the user_ The ID parameter is changed to the ID of another user.

Please note that these steps are not comprehensive or clear. They did not specify that you need two test accounts to test for vulnerabilities. They also assume that you know enough about the application and its request format to perform each step without further instructions. Now here’s an example from a better report:

1. In example Create two accounts on. Com: account a and account B.
2. Log in with account aexample.com, accesshttps://example.com/Change password.
3. Fill in the required new password in the new password field located in the upper left corner of the page.
4. Click the change password button located in the upper right corner of the page. (screenshot of UI location)
5. Intercept and send tohttps://example.com/change_passwordPost request of user_ The ID post parameter is modified to the user ID of account B.
6. You can now log in to account B with the new password you choose.

Although the security team may still understand the first report, the second report is much more specific. By providing many relevant details, you can avoid any misunderstandings and speed up the mitigation process. This will help your company’s overall image and bring more business.

Step 5: provide proof of concept

For simple vulnerabilities, the steps you provide may be all that the security team needs to reproduce the problem. But for more complex vulnerabilities, it can be helpful to include videos, screenshots, or photos documenting your exploits, called proof of concept (POC) files.

For example, for CSRF vulnerabilities, you can include an HTML file embedded with the CSRF payload. In this way, all the security team needs to do to reproduce the problem is to open the HTML file in the browser. For XML external entity attacks, including elaborate XML files used to execute the attack. For vulnerabilities that require multiple complex steps to reproduce, you can take screenshots and videos of you walking through the process. POC files like this can save the security team time because they don’t have to prepare their own attack payload. You can also include any crafted URL, script, or uploaded file used to attack the application.

Your screenshot video can promote the development of the whole industry and let organizations and platforms have a look. Yes. We need such functionality.

Step 6: describe the impact and attack scenarios

To help the security team fully understand the potential impact of vulnerabilities, you can also describe reasonable scenarios in which vulnerabilities may be exploited. Please note that this section is different from the severity assessment I mentioned earlier. The severity assessment describes the severity of the consequences of the attacker’s exploitation of the vulnerability, and the attack scenario explains the actual situation of these consequences.

The following is an example of the impact section:
Using this vulnerability, attackers need only their user to change the user password_ id。 Because each user’s public profile page lists the user of the account_ ID, so anyone can access any user’s profile and find their user_ ID and change their password. And because of user_ IDS is just a serial number. Hackers can even enumerate all users_ IDS and change the passwords of all users! This vulnerability allows an attacker to take over anyone’s account with minimal effort.

A good impact section illustrates how attackers actually exploit vulnerabilities. It takes into account any mitigating factors and the maximum impact that can be achieved. It should never exaggerate the impact of mistakes or include any assumptions.

Step 7: recommend possible mitigation measures

You can also recommend possible steps taken by the security team to mitigate vulnerabilities. This will save the team time to start studying mitigation measures. Generally, since you are the security researcher who discovered the vulnerability, you will be familiar with the specific behavior of the application function, so you can well propose a comprehensive fix.

However, do not suggest a fix unless you have a good understanding of the root cause of the problem. Internal teams may have more background and expertise to provide appropriate mitigation strategies for their environment. If you are unsure of the cause of the vulnerability or possible fixes, please avoid providing any suggestions to avoid confusing readers.

You can propose the following possible mitigation measures:
The application should verify the user’s user in the password change request_ ID parameter to ensure that the user has the right to modify the account. The application should reject and record unauthorized requests.

You don’t have to delve into the technical details of the fix because you don’t know the underlying code base of the application. But as someone who understands the vulnerability category, you can provide mitigation direction.

Step 8: verify the report

Finally, always validate your report. Check your report for the last time to make sure there are no technical errors or anything that might prevent the security team from understanding it. Follow your own reproduction steps to make sure they contain enough detail. Check all POC files and codes to make sure they work properly. By validating your report, you can minimize the possibility of submitting invalid reports.

The more reports you write, the longer it will take. However, due to the high value, you can add money appropriately. It’s not a problem to be more expensive. The problem is whether it’s worth spending and time.

How to write a report

Insert picture description here

Other tips for writing wonderful reports

Here are other tips to help you provide the best possible reports.

不要假设任何事情

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

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

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

简洁明了

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

写你想读的

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

专业

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

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

How to write a report

在这里插入图片描述

与开发团队建立关系

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

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

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

了解报告状态

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

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

需要更多信息

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

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

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

信息量大

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

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

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

重复提交

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

N/A

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

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

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

漏洞管理与分类

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

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

解决

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

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

处理冲突

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

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

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

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

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

How to write a report

在这里插入图片描述

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

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

建立伙伴关系

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

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

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

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

最后

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

如果你正在学习怎么去寻找漏洞的话,可以关注我,学习更多网络安全黑客技术

点击查看【网络安全学习资料·攻略