In this article, we will try to provide you with a list of good practices and details to add to your reports before sending them for review. This should help you maximise your luck for a faster triage and ensure that the program owner will have all information to reproduce the vulnerability described and decide regarding the reward. The quality of your report ensures a good, fast and efficient triage. This list could also ensure that you have gone as far as possible in your exploitation to obtain an optimal reward.
Comply with the rules of the program
Is the vulnerability that I discovered is a part of the scope (domain, mobile application)?
Be careful to respect the scope indicated. Reporting on a vulnerability discovered in a domain or application that is not explicitly listed is generally not allowed by the programs.
Is the reported issue part of the program’s list of non-qualifying vulnerabilities?
Submitting a vulnerability that is clearly listed as a non-qualifying vulnerability will be probably closed without any reward and ranking points. This report will impact your impact rate. Check this list before submitting your report.
Could the report submitted on this program end up being a duplicate of one of your previous reports?
It may be tempting to submit multiple reports on the same issue. However, these reports could be considered duplicates. If you submit two reports on the same endpoint but with only one different parameter, a single patch will likely be sufficient.
It’s all about the Proof of Concept (PoC)
Now that you are confident that your vulnerability is on the scope and fits the rules of the program, you can think about your report and the PoC you will provide to reproduce it.
Does your Proof of Concept (PoC) have enough detail to allow anyone to reproduce it?
The team that developed the application being tested in the program is not always the same team responsible for reading the reports and reproducing the vulnerabilities. When writing your PoC, it is, therefore, vital to assume that the person who will reproduce your PoC does not know the application inside and out. Your PoC must be able to follow your steps and analysis. Have you described the feature you are using? What privileged account do you need to access this feature?
The more detail you provide about the context of this exploitation, the faster and more efficient the reproduction team will be.
Did you sufficiently demonstrate the current impacts and describe the potential impacts?
Your issue must justify a real impact to be accepted. If you are suggesting a CVSS with a high score, have you demonstrated those impacts to justify a reward? If you can’t prove it, you need to be able to explain the impacts you can achieve with your issue. This will help justify the CVSS you are suggesting.
Did you completely reproduce the PoC you described before submitting your report? Did you provide the initial endpoint to reproduce?
These are the two most common reasons for a “Need more info” update. A PoC is not functional if a step is missing. A double-check of the PoC with a new blank browser session will ensure that the replay is possible without limitations. Otherwise, the Program Manager will probably ask you for the missing steps.
Did the exploitation go far enough to justify an impact?
The higher impact, the higher the CVSS and reward. Why not leverage what the rules allow to justify the greatest possible reward? A Cross-Site Scripting (XSS) with alert(1) can be sufficient for some programs, but do not hesitate to exploit to the maximum of your knowledge to justify the impacts.
Some additional checks before sending your report
I find an XSS, great, it allows me to retrieve session cookies!
There is no guarantee that this cookie is a session cookie. It must be ensured that these cookies allow the victim’s session to be stolen. Otherwise, no direct impact on confidentiality is proven.
In any case, proving a JS execution for a payload of any size using an `eval(location.hash.slice(1))` will be good proof of potential impact.
During my research, I find a Server-Side Request Forgery (SSRF), great I submit it right away!
All impacts remain to be demonstrated. An SSRF may allow for bouncing around to other services, or it may have no impact. If the program rules allow it, it must be determined whether this SSRF has a real impact within the internal network or if it leads to a rabbit hole. This will significantly increase the severity of the vulnerability.
With this simple prerequisite, I achieve a significant impact! Great, I’m submitting this!
What is this prerequisite? Is it necessary to have an account created and validated manually by the application team? Do you need to have high computational power or a botnet? Do you need to obtain a UUIDv4 from the victim? Does the victim have to copy and paste a URL for the exploit to succeed?
The likelihood of obtaining this prerequisite should be considered before submitting your report.
I found this HTML injection, if the WAF didn’t exist, it would be an XSS, so it’s an XSS that I submit.
Indeed, without the WAF, this HTML Injection could become an XSS, but the WAF exists, so an attacker who cannot bypass it would not be able to achieve the impact of an XSS. So, without a WAF bypass, this issue will remain an HTML Injection.
I found the version of this software, and there is a CVE that allows an RCE, so the application is vulnerable, I can report it as RCE.
In most programs, reports containing CVE references without working PoC are among the non-qualifying vulnerabilities.
My scanner found a critical issue. I’m reporting it right away!
Many scanners produce false positives. Always check vulnerabilities manually. A copy and paste report generated by a scanner without manual PoC does not correspond to vulnerability exploitation. Many companies already use an automatic vulnerability scanner to protect their applications. The interest of the Bug Bounty is to search for vulnerabilities that a scanner could not detect.
While reversing the application, I found a vulnerable function, I submit this!
This function is vulnerable to attack, but there is no guarantee that an attacker could use it to impact a victim. Without a PoC demonstrating real exploitation, this issue does not demonstrate that an attack in this way is possible.
The Host header is reflected on the page, so I have a Host Header Injection!
In its current state, a Host Header Injection does not guarantee an impact. Everything depends on where the injection is reflected. A PoC demonstrating an impact on the application has to be done. For example, maybe you could try this issue on the forgot password feature.
I found something which seems to be a secret token (in JavaScript file, APK…), I can submit this!
Every hash or similar strings that you can discover on an APK or JavaScript file are not always a secret token. Before submitting your report, identify what exactly this token is and how an attacker could use it to perform malicious actions. We also recommend using KeyHacks, a great GitHub repository that lists many command lines for querying the API endpoints of various services via the retrieved token.