Hello dear ethical hackers and welcome to this new article about bug bounty hunting. If you’ve been following along from the beginning, you have hopefully found at least one bug by now. If it’s the case, then congratulations! Now it’s time to report that bug right? Well, I have been working as a triage Analyst for more than a year, and trust me when I tell you that only few hunters master the art of writing good bug bounty reports. If you don’t give enough care and love when writing, be aware that it is a mandatory soft skill which brings you higher bounties. Every hunter should know how to write good bug bounty reports. And today, you will see how you can do just that!
By the end of this episode, I will share with you a bug bounty report template which you can use as a starting point. However, you can’t do much with it if you don’t understand the idea behind it. So make sure to stay with me to get the maximum out of this episode.
Why you should write good bug bounty reports
A lot of the content on the internet teaches you the skills you need to find bugs. However, few talk about writing good reports. In this section, we will discover the benefits of quality bug bounty reports.
Good bug bounty reports speed up the triage process
To understand how good bug bounty reports speed the triage process, you have to put yourself in the place of the triage analysts. Everyday, they handle countless reports. If you write a poor bug bounty report, it will take him/her more time and effort to understand your bug, reproduce the steps and evaluate the impact. In contrast, if you communicate your bug in a structured way which clearly explains the reproduction steps and the impact, the triage analyst will quickly assess your bug bounty report. Therefore, you get a positive response as quickly as possible without having to bounce comments back and forth, with all the frustration that comes with it.
Quality bug bounty reports increase your rewards
Writing good bug bounty reports increases your rewards in three different ways. Firstly, it allows you to focus on finding new bugs because the team doesn’t have to request any further information regarding the reports you already submitted. Secondly, you might get a bonus if the bounty program’s team finds that your report helped them quickly and efficiently fix the issue. Finally, you might even bypass duplicates! In fact, many programs state in their policy that the first reproducible report is the one to be rewarded.
Great bug bounty reports give more value to your hacking skills
When you master the skill of communicating your findings in a clear and structured way, you add great value to your bug bounty reports. This comes handy when you want to show off your skills. In fact, you can simply reference your publicly disclosed reports in your CV. That way, you are giving a solid proof that you can not only find bugs, but also communicate them to developers in a manner which helps them quickly patch the vulnerabilities. Compared to other candidates, you will have much better chances of being hired.
Alright, now that you understand why writing good bug bounty reports is crucial in your career, let’s see how you can write one.
Your bug bounty reports structure
I’m sure you have done writing assignments at one point or another during your education at school. You certainly learned how important it is to structure your ideas into several sections. Well, writing your bug bounty report is no different. Don’t worry though, you will not have to write countless pages.
Structuring your content is your first key when you want to write good bug bounty reports. To achieve that, ask yourself one simple question: Is my report easy to follow? Then, read your report and be honest with yourself. If you spot any areas where the recipient might struggle with, try to enhance it. If you have no idea where to start, stick around until I give you a template that will make your life easier.
Besides, make sure that your report is well-formatted. Most of the major bug bounty platforms support Markdown, so make sure to learn how to use it. I’ve included an example at the end which should give you a quick start. Trust me, your report will look ugly and unprofessional when it merges raw HTTP requests, code snippets and your explanations without proper formatting.
Respect the scope
One big mistake most new bug bounty hunters make is failing to read the program’s policy, especially the part which details out of scope assets and known vulnerabilities. If you are one of them, pay close attention here.
When you report a bug, the first thing the triage analysts do is verifying if it is in-scope. In other words, they make sure that the asset and the vulnerability type are not listed as out of scope in the program’s policy. If it is out of scope, your report will be closed and you will lose your precious reputation and signal points. For those who don’t know why these are important, the higher they are, the more you are trusted. For example, on HackerOne, your reports will escape the Human-Augmented Signal step which typically captures reports with high noise probability. Therefore, your report will fall directly into the program’s inbox, saving you time. Besides, you will have higher chances of getting more interesting bug bounty program invitations.
So, make sure you double-check the program’s policy before investigating a potential bug.
A good bug bounty report is nothing without a clear impact statement. This is where you stand your best chances to increase your bounty. Take the time to clearly explain how bad your bug can affect the security of the asset you are targeting. For example, if you can list the content of an S3 bucket, make sure to check if there is any sensitive data. If it does, you should mention it explicitly. Most of the time, the program’s team will realize how bad it is. This is better than just telling reporting that you can list the bucket’s content, especially if it contains mostly static files. Another example is when you find a potential subdomain takeover. You should first claim the subdomain before even thinking of reporting the bug. If you can’t, it’s probably not possible to claim it.
Support your report
When you support your report with additional material, it becomes even easier for others to reproduce your steps and properly evaluate the impact. You can achieve this using different ways.
HTTP request and response
When you find a vulnerability involving HTTP traffic, make sure you include both the vulnerable request and the expected response. However, avoid pasting big content. The most important parts of the HTTP request are the first line and the vulnerable parameter. Don’t forget to properly format your report as explained earlier. To do that, put the HTTP requests inside a code block using Markdown to visually separate it from the rest of your explanations.
Screenshots can be useful in many ways. Sometimes, the user interface can be full of buttons, forms and menus. In this case, it is good to share screenshots pointing the vulnerable area. Other times, you might want to share proof that you have successfully exploited the vulnerability. For example, you can share a screenshot demonstrating your ability to exfiltrate internal files.
When to share a video?
Sometimes, the reproduction of the bug requires a lot of complicated steps. In this case, the best thing you can do is to include a video. Try to make it short, straight to the point. If you can speak while demonstrating the exploitation steps, it’s even better.
Maintain a professional attitude
Although writing good bug bounty reports reduces time to triage, you might still encounter some hurdles during the report’s lifetime. For example, I once reported a bug which wasn’t reproducible on the triage analyst end. After some comments back and forth, the triage analyst closed the report as Not Applicable. For those of you who are not familiar with the HackerOne report states, this is the worst case after Spam reports and it significantly reduces your reputation. Instead of swearing and yelling at him, I wrote a professional answer and attached a video proof. After further investigation, he found that our environments were not configured the same way, which explained why he wasn’t able to reproduce the bug. Then, he reopened my report and triaged it.
You must think well of others and preserve a professional attitude when you communicate with the triage analysts or the program’s team. At the end, we are all humans and we make mistakes.
Your report template
In this section, I will share with you the template I use for all my bug bounty reports and how I write the content. So far, all the teams I have worked with have positive feedback regarding the quality of such a template.
Title of the bug bounty report
I always give my title the best care. It’s the first contact with the triage team and it plays a critical role in putting their minds in the correct context. I always avoid generic titles which don’t give any clue whatsoever. Remember that you should make their life easier and speed up the triage process. Let’s assume that I found a cross-site scripting vulnerability. Well, I make sure to include the type, the vulnerable asset, the target endpoint and the weak parameter. Your title should look like this:
Reflected Cross-site Scripting on xyz.com on the xyz endpoint in the xyz parameter.
This title will condition the triage analyst’s mind and quickly give him/her an idea of what this report is all about in only one sentence.
The summary section
This is where you write a short paragraph describing the vulnerable feature and how it is vulnerable. You have to do this because, on the one hand, the triage analyst is not necessarily familiar with the application. On the other hand, it is a great introduction to the reproduction steps which come next.
Sometimes, the vulnerability can be complex enough to be summarized in one short paragraph. In this case, you can still preserve the summary section and add a description section which explains more technical details about the vulnerability. The reason behind preserving both the summary and the description is that the triage analyst can quickly look at the summary. If he or she would like to know more, the description part will serve the need.
Steps to reproduce
In this section, you should pay close attention to the details. You have to make sure that you can reproduce the steps yourself based on what you’ve written. Always include HTTP requests as explained earlier to support your steps and don’t forget to verify that they are well formatted.
The steps should give a clear and easy-to-follow walkthrough that anyone can reproduce. If you have used a script, make sure to include it as well. If you feel a screenshot is needed, embed it using Markdown instead of just uploading it. It makes your reproduction steps pretty and easy to read.
This is where you explain why your bug deserves the biggest bounty possible. Take your time to come up with the highest impact and communicate it well in this section.
This is optional, but if you have a suggestion to fix the issue, you can add it in this section. For example, if you have already done your analysis and found exactly where the problem lies, it would be a plus to include a mitigation paragraph. Who knows, you might get a bonus if you save the team countless hours of debugging and root cause analysis.
Below is the bug bounty report template with the Markdown code, followed by a screenshot of how it looks like on HackerOne.
## Summary: An introduction to the application's feature and your vulnerability. ## Description: In-depth technical details in case the bug is complex. ## Steps to Reproduce: 1. Step 1 1. Step 2 ``` Raw HTTP request and response goes here ``` ## Supporting Material: Screenshots, video ``` script you have used goes here ``` ## Impact Clearly explain how the vulnerability affects the system ## Mitigation A bonus if you want to explain how to fix the vulnerability
Writing good bug bounty reports is a rare skill. If you master it, you will notice that your experience in reporting your bugs is smoother than before. As you saw in this episode, it’s no magic! You just have to put yourself in the shoes of the recipient and maintain a professional attitude. Besides, with the template I shared with you, you already have a solid structure to start with.
I hope this episode was helpful to you. I encourage you to like and share it. If you’re not subscribed yet, join us to get updates whenever I publish new content. The newsletter is on your right. Until then, stay curious, keep learning and go find some bugs!