Introduction

If you’ve ever felt some frustration at the report submission process and timeline, you’re not alone. Starting on the bug bounty journey can be challenging – reports can take time to be validated, or you find that reports get closed out as duplicates or not applicable. As a triager at HackerOne, I want to find scenarios that make everyone win. A quality report from a hacker gets a quick fix for a program, and that means a quicker payout award back to you. 

If you’ve ever wondered what could speed up the review process so your findings can get resolved and awarded quickly, then I’ve got great news for you! This blog covers tips for hackers on submitting quality reports and avoiding pitfalls that delay resolution or lead to closure as N/A or Duplicate.

Submitting a Quality Report

From a triage perspective, making your report concise speeds up the triage process, enables quicker issue validation, and expedites its presentation for program resolution and payout.

Here are a few tips on how to improve the quality of your submissions to make things move more smoothly:

• Select an asset & set the severity of each report. This will save you some headache from submitting reports that might be out-of-scope, and the severity setting can give us insight into how impactful this issue might be. (More on the severity in a moment).

• Provide a summary up front. Something succinct that illustrates the relevant vulnerability and what it means sets the stage for what you’re reporting

• Tell us how to reproduce this. Attention to detail is key! Provide comprehensive, step-by-step instructions outlining the workflow for both triage and the program to replicate your issue. Additionally, consider using visuals, such as images, to enhance clarity. Some triagers may appreciate a video proof of concept (POC), but only if it is concise and to the point (less than 2 mins). 

• Explain the impact. Why is this important for the business? What might someone with bad intentions achieve if they take advantage of this weakness in a real situation? Describe in simple terms how this vulnerability could lead to actual problems for the program, and clarify your thoughts by explaining the CVSS score in detail. You can find additional details on this subject in the section labeled "Proving Impact" below.

In fact, many programs have template report requirements that already adhere to these best practices. So adopting this mentality as you begin your hacking journey with HackerOne not only makes things smoother for those triaging your reports, but aligns with what programs are looking for in their submissions! You may have even seen it. A typical structure would look like this:

## Summary

A quick description of the issue. Example: A stored XSS vulnerability exists on the endpoint `www.asset.com/the/path/to/xss` via the parameter `vulnerable_param`.

## Reproduction Steps

1. List out a detailed step-by-step breakdown of how to reproduce this vulnerability.

2. You don’t need to overstate everything, but make sure all the relevant details are there.

3. Note any special permissions that are required, or if the vulnerable element is buried somewhere, give us a URL path to the location or steps on how to get there.

4. If it’s something like Stored XSS, noting the POST endpoint and the vulnerable parameter is helpful! 

5. Screenshots that help clarify the impact and prove your finding should be included as well.

6. If you have code snippets or want to share HTTP requests with us, use proper [formatting](https://docs.hackerone.com/organizations/using-markdown.html) to help make things readable and quick to reuse when we test it.

## Impact

Describe the impact from a business or user perspective. What are the implications of this issue for the business? For the victim? What does an attacker gain from this? This is your chance to help sell the importance of your finding.

For example, if you find a Reflected XSS vulnerability on an asset, you can help sell your idea on severity if you explain the level of damage an attacker could get away with. Can you access the victim’s session cookies and take over their account? Is this a flagship or critical application?

Avoid pitfalls and closures

I said it at the start, but one of my goals is to make HackerOne a great experience for everyone – the hackers, the programs, and (selfishly) triagers/me. With that in mind, let’s talk a little about some of the pitfalls that can exist and sometimes feel frustrating: reports delayed by NMI (needs more info), closed as N/A, and closed as Duplicate.

1. Needs More Information is not there to annoy you. When we shift a report back to you for more information, it’s usually because something is unclear in the initial report. You can avoid a lot of this confusion, by following the steps above. More often than not, NMI occurs because a step to reproduce was left out. Sometimes there’s a discussion on the relevance of the finding (is this actually an issue?), or because we are unable to reproduce it (Is the issue still there? Was it unique to your test environment?). If you’re following steps to be as clear as you can on impact and reproduction steps, look at NMI not as a roadblock or a hurdle, but as a collaboration between you and triage to really understand the full impact of an issue.

2. Perform due diligence to avoid N/A or Informative. We have a lot of programs on HackerOne, and as a triager, we regularly have to get acquainted with the unique policies of each program. Reports getting closed as N/A or Informative are often because they are either: 1) assets not in scope for the program, or 2) vulnerabilities that are not of interest to the program. Before you submit your report, take a moment to read through the program’s policies and scope to make sure that both your asset and the vulnerability are in scope! If you hack one program for a while, you might even want to take some notes of your own to help keep things aligned. (For example, some programs will consider reports on assets that are not explicitly mentioned in scope, but other programs will not. Save yourself some heartache by checking first or keeping a note of preferences). I do that on the Triage side, and if you do it too you can avoid seeing all of your effort get closed out as N/A or Info.

3. Duplicates. It’s hard to know if a report you’re submitting has been submitted before. As part of a review process for any new report, the HackerOne team searches previous submissions to see if the issue has already been reported. Quality reports make it easier for us to perform duplicate checks. If you’re new to HackerOne and you’re worried about your report getting closed as a duplicate:

   1. You can check the program’s disclosed reports and see if your issue exists there.

   2. Don’t be! There is a positive impact to your reputation if the original report is resolved and not yet disclosed.

Proving Impact

Lastly, a word on severity. It can be frustrating when a triager or the program downgrades the severity of an issue that you’ve reported. The triage team usually assesses each report against the Common Vulnerability Scoring System (CVSS)  (although there are exceptions – make sure to check each program’s policies to understand how they judge severity). When you submit a report, I encourage you to use the CVSS calculator to assess the severity.

The CVSS calculator tool on the HackerOne platform does a good job of explaining what each metric means and how you can assess high/low/none for each field, so I won’t go into that in detail (although you can check out some good reference examples from FIRST.org as well as HackerOne’s Platform Standards). I would highly encourage you to offer your opinion on why you are setting the CVSS, as it provides valuable insight into your thought process and helps us better understand your perspective.

For example, if you found an IDOR (Insecure Direct Object Reference) that allows the deletion of user profile data, you might fill out the CVSS with the following notes included in your report submission:

• Attack Vector: Network - this attack takes place over the internet

• Attack Complexity: Low - the profile data is stored as a sequential integer

• Privileges Required: None - the attacker can self-sign-up for an account

• User Interaction: Not Required - the victim does not need to interact with the attacker to accomplish this

• Scope: Unchanged - the impacted/vulnerable components are the same

• Confidentiality: None - no disclosure of sensitive data

• Integrity: Low - modification of profile data, but only profile data

• Availability: None - data deletion is an integrity issue and has no impact on service availability

Punch this into the CVSS calculator, and you would assess this as a Medium severity finding. If the triage team has different opinions, at least now there is some understanding of where you’ve assessed this impact, and we can communicate with you about where we see differences in severity and score. Of course, CVSS may not be able to capture every issue with its system, so that’s where a description of your impact statement can help elevate your severity and make the case that something might need to be higher than CVSS can account for.

Final Thoughts

One of our core values at HackerOne is “Default to Disclosure” — that means when we can, we try our best to be as transparent as possible. The secret to a good report shouldn’t be a mystery, nor should you have to guess how to avoid the common pitfalls of report closures or report severity. With some of the tips outlined above, you should be able to start down the path of a successful and rewarding journey with HackerOne. Happy hacking!