Help Center

Step by Step: How to write a good vulnerability report

Report Title

  • Include vulnerability type (XSS, CSRF, XXE, SQLi, SSRF, etc)
  • Include vulnerable (sub)domain and/or endpoint/component (www.site.com/patht/to/file)
  • Example of good titles:
    • Reflected XSS in dashboard.bugbountyprogram.com/profiles via name parameter
    • Remote Command Execution in upload.bugbountyprogram.com/upload.php
  • Examples of a bad titles:
    • Stored XSS foundbugbounty.com

Report Format

While writing a vulnerability report it is important to include every bit of important information within your initial report. Before writing your report keep a few things in mind:

  • Your report could help determine the appropriate bounty amount.
  • The person reading your report only knows about your vulnerability as much as you allow them to, so remember to provide as much information as needed for them to reproduce the bug.
  • If you are unsure of the Engineer/Analyst on the program, write your report as though someone with no experience with the application is able to reproduce the issue.

**Acceptable Report:**

Title: Stored XSS in app.bugbountyprogram.com via user signature.

Hey there, while testing your program I came across a XSS vulnerability in the forum by abusing the user’s signature.

Reproduction Steps

  1. Visit app.bugbountyprogram.com and login to your account
  2. Click on the “account” menu and click on “Profile”
  3. Scroll down and insert <script>alert(document.domain)</script> as your signature and click save.
  4. Visit the forum and make a new post with title as “XSS TEST” and The body as “TESTING FOR XSS”
  5. Once you create a new thread, the xss should trigger.

Exploitability

Since the attacker’s post is publicly accessible, this vulnerability could affect all users on the given subdomain. Furthermore, this could be used to perform actions against the administrators (or any user visiting that page) and could potentially lead to hijacking the user’s session/token. This could happen by users navigating to the attacker’s post on their own, or by the attacker somehow persuading the victim to navigate to the post.

Impact

Hijacking an administrator’s session would allow an attacker to perform actions such as: edit or deleting content, posing as the admin to socially engineer other users, or any other actions the admin has access to.

The example above has five key items to help the engineer/analyst to triage the given issue:

  • The vulnerable domain
  • Reproduction steps
  • Attack vector/payload
  • Exploitability
  • Impact

If you ever find yourself in a situation where the vulnerability seems more complicated to reproduce, feel free to attach screenshots to the report that help illustrate each step of the attack. For example:

Title: Stored XSS in app.bugbountyprogram.com via user signature.

Hey there, while testing your program I came across a XSS vulnerability in the forum by abusing the user’s signature.

Reproduction Steps

  • Visit app.bugbountyprogram.com and login to your account
  • Click on the “account” menu and click on “Profile”, scroll down click on edit signature (screen1.png)
  • Scroll down and insert <script>alert(document.domain)</script> as your signature and click save.
  • Visit the forum and make a new post with title as “XSS TEST” and The body as “TESTING FOR XSS”
  • Once you have created a new thread xss should trigger. (screen2.png)

Exploitability

Since the attacker’s post is publicly accessible, tThis vulnerability could affect all users on the given subdomain because it is publicly visible if the attackers post is viewed by any other user on the platform. Furthermore, this could be used to perform actions against the administrators (or any user visiting that page) and could potentially lead to hijacking the user’s session/token. This could happen by users navigating to the attacker’s post on their own, or by the attacker somehow persuading the victim to navigate to the post.

Impact

Hijacking an administrator’s session would allow an attacker to perform actions such as: edit or deleting content, posing as the admin to socially engineer other users, or any other actions the admin has access to.

 

**Unacceptable Report:**

Title: Stored XSS Found!

  1. Visit your site and set an XSS payload as your signature
  2. Go to forum, make a post, and get XSS.


This report is unacceptable for a variety of reasons - it doesn’t provide enough detail for the engineer to reproduce the issue, it doesn’t provide the affected URL, there’s no description of exploitability or impact, etc.

The “acceptable” example above doesn’t work for every vulnerability report/type. To increase your chances of getting your report triaged first time around include any file, information or details that may help. For example if your attack vector requires to change the POST data manually using a 3rd party tool such as Burp, provide an example in the written report.

Title: Local File Inclusion in app.bugbountyprogram.com in POST data via template path.

Hey there, the app subdomain is vulnerable to a Local File Inclusion (LFI) attack. I was able to do so by changing the POST data in sent to /preferences. Here are the reproduction steps:

  • Login to app.bugbountyprogram.com
  • Click on the gear button located on right hand corner of the dashboard and select personal settings.
  • Change your theme option from default to any of the options available.
  • Before saving your changes, make sure burp is running to intercept the request.
  • Change the value for the template variable in the POST data to ../../../../../../etc/passwd as shown in the example below.

GET /preferences HTTP/1.1
Host: app.bugbountyprogram.com
Connection: close
User-Agent: [...]
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: en-US,en;q=0.8,fa;q=0.6
Cookie: [...]

template=../../../../etc/passwd

This allows user to read files located on the server. If you need any help with this report please do not hesitate to ask.

Q&A:

Do I need to provide the HTTP request for all my reports?  

Although providing HTTP request could be helpful for any type of report, it is not required or needed. For example some vulnerabilities may be straightforward and easy to reproduce, while other reports may require some adjustment in the HTTP request in order to exploit the issue. In that case it is always best to provide the request to make sure the analyst/engineer on the report has every bit of information necessary.

Can I record a video instead of writing a report?  

Videos could become very helpful for the more complicated POC’s, however they may take up more time and resources in order to reproduce an issue. In most cases a well written report with some screenshots (if any) will result in a faster response and validation process than downloading, watching, and finally reproducing the issue. 

How long should I wait before asking for an update or a follow up?

This case varies depending on the program the vulnerability is being submitted to, but we recommend allowing up to 10 days before requesting an update.

What if I don’t get a reply from a program after waiting 10 days?

While making a new comment on your submission, you are able to click on the “Request Mediation” button to get help from HackerOne. We do ask you to not disclose any submission details while requesting mediation.

Should I contact the company outside of HackerOne by using support or any 3rd party websites?

It is best if all communications between hackers and programs are kept on the platform. If there’s an emergency or a problem with a program, feel free to email support@hackerone.com.

 

Have more questions? Submit a request
Powered by Zendesk