Bug bounty reports are your ticket to either top ranks on a platform or the lowest level of humiliation. Good bug bounty reports lead to good relationships with the bug bounty team and better payouts eventually. If the vulnerability report indicates the following signs then your report is indeed a good report
- Faster response time from the security team responding to your request
- Better reputation and relationships with the security team
- Higher chances of getting a bigger bounty
- In this chapter, we will learn about the following topics:
- Prerequisites of writing a bug bounty report
- Salient features of a bug bounty report
- Format of a bug bounty report
- Writing the title of a report
- Writing the description of a report
- Writing the proof of concept of a report
- Writing the exploitability of a report
- Writing the impact of a report
- Writing remediation
- Responding to the queries of the team
Prerequisites of writing a bug bounty report
Even if you have identified a highly critical vulnerability in the application of a bug bounty program, if the vulnerability report is not clearly written and explained, there are chances
that the vulnerability may be rejected by the program. Before writing a bug bounty report, It is crucial that you identify the nature of the program.
Bug Bounty
Referring to the policy of the program
Reading the scope of the bug bounty is probably the most important thing you should do before even looking at the program's website. It will be really frustrating when you spend a
week looking for vulnerabilities in a bug bounty program only to find out that the domain that you tested is not included in the scope. The conventional scope of a bug bounty program contains the following bits of information:
- Mission statement
- Participating services
- Excluded domains
- Rewards and qualifications
- Eligibility for participation
- Conduct guidelines
- Non Qualifying vulnerabilities
- Commitment to researchers
Mission statement
The mission statement of a program is its foreword and explains the reason of the company for starting the bug bounty program. It explains the mission that the company has behind
starting the program and the collective outcome that the program vendors want to achieve out of running this program.
Participating services
The participating services section in the bug bounty policy of a program includes a detailed list of the included domains that are in the scope of testing. This is a very explicit section
and one of the most important sections in a bug bounty program and should be analysed very carefully. Typically, the domains that are listed in a program are written as testingsite.com and if the subdomains are also included, the details are in *.testingsite.com. The longer the list of subdomains in this section, the more chances there are of finding a vulnerability in the program. Another thing to keep in mind is to keep a close eye on this section as programs frequently update this section of the policy to include new targets and domains. Bug bounty programs are generally first come, first served. If the bug bounty program updates its scope and you are the first one to know about it, it is highly likely that you will find a number of critical vulnerabilities in that domain. However, that being said, it is advised that you test each domain thoroughly with full concentration to look into critical vulnerabilities.
Excluded domains
This section is also important to look at as it contains the details about those domains that it is prohibited to test. Sometimes bug bounty programs deploy their applications on test servers and mention their original websites in the excluded domains section so as to prevent unwanted data traffic and server downtime.
Excluded domains are out of the scope of testing and result in repercussions when tested and reported. It is strongly advised to look for the excluded domains section and review it before testing the applications.
Reward and qualifications
This section outlines the expected rewards with respect to the vulnerabilities in a tabular form. The sections contain the category of the vulnerabilities and the reward for core applications and non-core applications. The payout ranges are listed in this section to give an idea to the researcher of what to expect in regards to which vulnerability.
This is to notify the researchers what to expect from a vulnerability and the vulnerabilities that are rewarded higher than others. Setting this benchmark allows the program owners to justify their rewards after they have resolved a vulnerability and it reduces the chances of debate in the process.
Conduct guidelines
This section gives details about what a researcher should specifically never do when finding vulnerabilities in the program. It is a notification paragraph, stating that while the
disclosure of vulnerabilities is highly appreciated, there are certain things that the researchers should not do, such as:
- Disclose any vulnerabilities or suspected vulnerabilities discovered to any other person
- Disclose the contents of any submission to the program
- Access private information of any person stored on a program's product
- Access sensitive information
- Perform actions that may negatively affect the program's users
- Conduct any kind of physical attack on the organisation's personnel, property, or data centres
- Socially engineer any employee or contractor
- Conduct vulnerability testing of participating services using anything other than test accounts
- Violate any laws or breach any agreements in order to discover vulnerabilities
Non Qualifying vulnerabilities
This section lists all of the vulnerabilities that are explicitly out of scope. It lists the vulnerabilities that have been reported before or are not considered as critical enough to be reported. This is usually a long list of vulnerabilities that include commonly reported issues, such as:
- Bugs in content/services that are not owned/operated by the program
- Vulnerabilities affecting users of unsupported browsers
- Subdomain takeovers for out-of-scope domains
- Self-XSS or XSS bugs requiring an unlikely amount of user interaction
- CSRF on forms that are available to anonymous users
- Clickjacking that is, user interface hijacking on static pages
- Error messages
- HTTP 404 codes/pages or other HTTP non-200 code/pages
- Fingerprinting banner disclosure-public information disclosure
- Disclosure of known public files or directories
- Scripting or other automation and brute forcing of intended functionalities
- Presence of application or web browser "autocomplete" or "save password" functionality
- Lack of secure and HttpOnly cookie flags
- HTTPS mixed content
- Missing HTTP security headers, specifically-Strict-Transport-Security, X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, and Content-Security-Policy
Salient features of a bug bounty report
Every bug bounty report is different in terms of its technical details but every report has some features and aspects that are common and generic, which provide extra insights on the vulnerability that was identified. The following are some pointers that you can take into account while writing bug bounty reports.
- Clarity
- Depth
- Estimation
- Respect
Format of a bug bounty report
Based on my experience with bug bounties and pen test platforms, I have learned that a well-written report will make a major difference to your success. Over the years, I have
developed a clear understanding of how to report flaws in a program and which flaws to report. This has led me to formulate a format for reporting, but this format is not universal
and it may vary from person to person and case to case. But, it is something that you can adopt for clear reporting.
Writing title of a report
The report title is the first thing that the program owner looks at and notices about your report. The report title should be explicit and to the point. If the report title has emotional
involvement in it, it is often not considered as a positive factor by the program owners. The title is the first impression about your report that the program owners get and it is what
shows the level of maturity of the reporter and their experience. A straightforward title should be the starting point of your report. The following are a few examples of bad report titles:
Urgent! SQL injection found
Attention! Critical vulnerability
Very critical account takeover flaw
The following are some examples of to how you can craft your title better:
Union-based SQL injection in developer's portal
Hostile subdomain takeover in admin.xyz.com
Account takeover using password reset token
Writing the description of a report
The second part of the report is the description. A description must be precise, clear, and to the point. Program owners want to have direct engagement with any text so they do not
have to read much and can pick out the salient points easily. The description should not be something generic; it should be environmental and scenario-specific. This allows report
readers relate to the reports closely rather than thinking of them as generic. Describing a vulnerability is not an easy task for a reporter. However, a method to describe a flaw in a to-the-point and a clear way is to provide links for issues that can help program owners understand, identify, and resolve the issues in a report. The reference links can be taken from technical resources, such as stack overflow, the Open Web Application
Security Project (OWASP), and so on. It is not advised to copy and paste links and descriptions from automated tools and online sites. This gives a very bad impression about the reporter and shows that they did not have time even to write their own general report.
Writing the proof of concept of a report
Without the proof of concept replication steps, there is no way that the team can recreate the scenario that you just created, so it is important that you list down the steps exactly as
you replicated the vulnerability. You should always treat the program owner as a newbie when explaining the proof of concept to them. This way, you can list down all of the steps
in a hierarchical manner. Having simple, easy-to-follow, step-by-step instructions will help those triaging your issue to confirm its validity at the earliest opportunity. For instance, if I
identified an XSS vulnerability, here is what the replication steps would look like:
Go to the following [URL].
Log in using your username and password (you need an account to do this)
On the search box at the top-right, insert the following information:
<script>alert(document.domain);</script>
Click the Lookup button
You'll see a JavaScript popup box showing your domain
