How to write a good report
Writing a good report is as important as finding the vulnerabilities. Providing an unclear proof of concept can slow down the process of triaging your submission. So in this article we will give you some tips on how to increase the chance of your report getting accepted.
When making a submission, try to use markdown to make the submission more clearer. (Take a look at the markdown guide to get you started) A clean report is easier to triage and more pleasant to read for both the company and triage team.
Be polite! When you have troubles with a certain submission you can request support via the “Request support” button in the submission. Or if you have scope questions via the “Ask scope question” button on the right in the program description. (Submission lifecycle)
Patience is a virtue, you are probably not the only one waiting for an update or get your report triaged.
Before submitting or even before starting to search for vulnerabilities read the program scope section! You can save yourself and the triage team a lot of time.
When registering on a site, most programs require you to use your intigriti.me address otherwise it might be possible that the program rejects your submission or does not reward you for violating the rules. (What is my intigriti.me address and how do I use it?)
The submission
Title
In contrast to other platforms, we ask you to not include the URL in the title. There is a separate field for the endpoint when making a submission. A good title could be “Reflected XSS in search parameter” or “IDOR on download personal data”.
Description
The description can be a short summary/introduction about the vulnerability you found. Or it can be a detailed explanation where you describe the vulnerability and the steps on how you got to that point.
Proof Of Concept
Our triage team when they see a submission with no (working) PoC
Provide clear steps, something that is obvious for you might not be that obvious for the triager or the company. Be straight to the point without leaving out any details.
Don’t steal or change data from accounts you don’t own!
In the case of XSS, use document.domain or document.cookie instead of 1 or “XSS by Inti” or try to escalate it to an account takeover for example.
Only include images or video’s when it’s an added value. There is no need to include an image or video/gif that your XSS popped successfully. (Golden tip by EdOverflow!)
Try to make it as easy as possible to reproduce your issue by creating a curl request for example (without letting out important details of course).
In some cases it’s important to include in what browser or environment you reproduced your issue. Some examples are if the XSS pops in all the browsers or just Firefox, or when your pentesting mobile apps include the android/iOS version, or certainly when you are hunting on the FOSSA programs it is important that you include what operating system you were using.
Impact
One of the most important parts of the submission is the impact. Ask yourself what can I do with this vulnerability and if this bug were exploited, what could happen and why would this be an issue. Describe what damage can be done to the users or to the company, what is the real-world business impact. Sometimes this can be quite short when for example you have an IDOR that is leaking sensitive data.
Extra info
Sometimes the program requires extra information like “What was the IP address used when the vulnerability was discovered?” or “Time (CET) of the attack”. Try to fill these in correctly, as this might help speed up the process of validating your submission. For those who don’t know how to find their public ip address => http://whatismyip.host/
Want more?
BSides Leeds 2019: Confessions Of A Bug Bounty Triager – Glenn Pegden
Tips on how to improve your reports by Google Bughunter University