How to write a report

How to write a report


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“ 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: 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( 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:

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.

stay 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( provides a severity calculator based on CVss level (HTTPS://。

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 visit
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, access 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 to 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




















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

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










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



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

How to write a report