Writing a good and detailed vulnerability report
When writing a vulnerability report, it is necessary to provide as much information as possible to help the security team understand and quickly process the report, or it will end up taking longer for the bug to be fixed. From the HackerOne article “Step by Step: How to write a good vulnerability report”, this article briefly explains each component with additional sections required to create a good and detailed vulnerability report.
- The first, and most important, component is the report title. A good report title is a combination of vulnerability type, domain or endpoint, and where the vulnerability occurs — this can be a request parameter or attacking method. The report title should be descriptive and focus on the main point, for example, “Stored XSS at ABC.com/post via msg parameter”.
- Description is the introduction part of the report. This can be considered as a short explanation of the report title, where the reporter gives general information of the vulnerable endpoint or component, followed by the type and causes of the vulnerability found.
- Reproduction is the most important part of the report. Written in the attacker’s perspective, this includes detailed steps for the security team to follow. Attached images, proof-of-concept files or captured video links can be used to help explain some of the complicated steps. Make sure all required steps are included so the report can be checked and fixed in less time.
- Attack vector or payload contains tools or commands used to perform the attack; this is usually included in the reproduction or can be a separate section. Reports like XSS or RCE must provide working input strings or commands as demonstrations, but they must be safe to execute. For example, a simple command showing an alert box is enough for an XSS report.
- For a more complex vulnerability, the reporter may provide an exploitability section that tries to explain example cases and conditions for the attack to work. Most reports on privilege escalation or access control bypass need explanations and are more complex than reports on SSRF or SQL injection, as they depend on various endpoints and require users’ interaction.
- The impact of the vulnerability reflects the severity of the report. By referring to the result of the attack, try to explain what the attacker can do, what information they can access and how this affects other users in the system. The higher the severity, the higher the awarded bounty.
- The Recommendation section optionally provides possible solutions for the security team to resolve the vulnerability. It also shows the causes of the vulnerability, if not being discussed elsewhere in the report.
- Reference is located in the bottom of the report, and it contains links to external sites related to the vulnerability. This section is optional, and is often included only if the report contains new or complex attack techniques.
Sample Report Form:
Some components are optional in a trivial report. For example, most reflected and DOM-based XSS reports can contain just a short description and reproduction steps as they are well-known attack types. For a very complex one, it is acceptable to have more than one reproduction section if many endpoints are related to each other, or it can be split into two or more submissions.
These are the general components of a good and detailed vulnerability report. By including enough information, this will not only make the report readable and easy to follow, but it also helps the security team to quickly reproduce and fix the bug. It will also occasionally increase the bounty amount.
Reference:
This article is part of the HackerOne Platform Documentation: https://docs.hackerone.com/hackers/quality-reports.html
Some corrections made by: Christina D’Ambrosio
