When submitting vulnerabilities via the Bugcrowd's Crowdcontrol platform, it’s important to ensure that you provide enough information for the vulnerability to be validated. Without this information, the submission may be delayed or incorrectly marked, resulting in issues with the submission process. Obviously this is something that affects both researchers and the bounty owner.
Below we’ve put together a simple comparison of a good vs. a bad submission report, which shows why this information is so important for validation of issues.
The caption of your vulnerability is the first piece of information that’s visible to the bounty owner. You only get one chance at a first impression, so try to give a descriptive title that makes it clear what the bug is.
A well thought out caption should provide indication of what type of bug was found, and what general area of the application is affected.
Where possible, the type of bug should be selected from the drop down type list. If there is no specific type that matches the bug you’re reporting, then select “Bug/Other”. Selecting the correct Bug Type will show input areas for information specific to that type of bug.
URL / Location of bug
Entering the complete URL assists the bounty owner in identifying the exact location of a bug. Some applications are complex, so it’s important to know where the bug is located.
Although both technically correct, you can see how the good example above provides a link not only to the domain affected, but also to the location and function where the bug exists.
Location where XSS is accessed once stored (if relevant)
Some bugs may require additional information in order to fully understand the risk, and how they can be exploited. By entering this information, it is easier for the bounty owner to validate the bug quickly, and without requesting further clarification from the researcher.
The severity of a bug can be greatly affected by a number of factors. By confirming if the bug is exploitable by authenticated users only, or by all users, it is easier to validate and correctly rate the severity of issue.
Trace dump/HTTP request
In order to validate web application issues, it is important to know what request(s) were used to trigger the bug. Although the bug you’re reporting may seem obvious, this is an important piece of information for those validating the issue who may not be as technical, or understand the exact issue you’re trying to describe.
In instances where specific parameter(s) are being exploited, it is important to know which parameter(s) are vulnerable to this bug. You can list one or more parameters.
Attack String (Payload)
A specific test case should be provided in order for the bounty owner to quickly validate the finding and understand where the issue lies.
Steps to replicate
This section of the report is probably the most important of all sections, as it should contain a full walkthrough of the steps needed to exploit the issue. If this walkthrough isn’t easy to follow, then the bug may incorrectly be marked as “not reproducible” or additional information may be requested (therefore delaying the processing of the issue)
Any additional information
This field should be used to convey further information that may be useful in understanding or rating the severity of issue. If the issue is not clear, then this field can be used to explain the risks and possible attack vectors for the bug. This section can also be used to communicate possible remediation advice.
How did you find this bug?
Information on the method you used to find the issue
What tools did you use to find this bug?
Any special tools that you used to assist in locating or exploiting the bug
By uploading screenshots or additional documentation, it is easier for the bug to be verified and correctly handled. Uploaded files can include screenshots of the exploitation (pre and post) or other supporting documentation (POC Scripts, Log files etc…). A file attachment isn’t a replacement to the rest of the data required for this form however.
If you follow all these best practices in reporting issues via Bugcrowd then you’re in the best possible position to have a smooth and seamless experience.
Complete report comparison
Once you bring all these sections together you should now have a complete submission. If you've followed the suggestions above yours should look more like the one on the left, and less like the one on the right...