While bug hunting, accuracy and quality of the report plays an important role in results and rewards.
“My report was triaged and after a while the status was changed to duplicate. Why? Why is a valid report marked as n/a? I originally had a P1 report, but the status changed to P2 or P3. Why?” My answer: because reports aren’t always perfect.
Based on my experience and journey (completing nearly 150 P1 reports on Bugcrowd), writing reports can be very rewarding. I even got some awards for duplicate reports that I sent because the customer liked the report, POC, impact.
I will put some examples from my experience and previous reports and some mistakes that should be avoided in bugs/reports near the end of this blog, so be sure to check those out.
The first impression of the report is taken from the title, so it’s important to give the best explanation to show what the report is regarding.
Examples of low-quality titles:
Examples of high-quality titles:
The description should be brief and clear by explaining what the bug is and how you reached it.
Example of low-quality description (github leak):
Example of low-quality description (sql injection):
Example of high-quality description (github leak):
Example of high-quality description (sql injection):
Testing on wide scope: If you find a bug on ip/domain while wide scope testing, you have to prove that the ip/domain is owned by the program by adding ssl check, reference from google/wikipedia/program/etc.. to save time for both the triage team and customer.
For example, I found a P1 on a wide scope program on domain. The client did not know that they had this domain, so the customer asked me to add my full recon steps for internal investigation.
If the bug is easy to reproduce then it’s okay.
Example:
Example 1: You access to end point and are allowed to create an account with full login information, then you access to some end and are allowed to inject.
Example 2: Sql injection in login panel as post request
Note: If you used sqlmap, it might take a long time for you, so add full command for dbms and sql title to save time. For example, “sqlmap -r request –force-ssl –level 5 –risk 3 –dbms=”xxx” –test-filter=”title””.
The most important aspect of the report is to show impact. More than 70% of hunters just copy and paste general impact in the report, but you must understand the impact, as the bug might be the same, but the impact could be different. For example, stored XSS in your profile setting is not like stored XSS in normal endpoint.
Github leaked credentials example:
Sql inaction example:
It’s necessary to focus on markdown when writing a report. You can find a cheatsheet for markdown here. Below, I will present the most efficient usages of them.
Photos and videos also play an important role in reports! Why? For example, you find a bug and send the report. Then, the customer fixes it before the report was triaged. In this case, it acts as evidence, saves time for triagers, and avoids confusion.
1) If you find the same bug on different subdomains, submit them as one vulnerability. If you submit the same bug multiple times with different subdomains, you may self-duplicate your findings.
3) Ips reports: If you find the same bug for same sub domain on different ips, it’s just 1 report.
If you write an excellent report and show good impact, I guarantee that both the triage and customer team will cooperate with you, even if your report is a duplicate. I got 3 bounties on 3 duplicate reports.
Examples of comments from customers about writing reports
Thank you for reading this report. Keep on hunting! Godfather Orwa | Bugcrowd
About Me:
My name is Orwa Atyat and I am from Jordan. I’m a full-time bug hunter with 130+ P1’s submitted. I’m ranked 65th all-time on Bugcrowd and was awarded top 10 in the P1 Warrior Rank.
Every minute that goes by, your unknown vulnerabilities leave you more exposed to cyber attacks.