Submitting Reports
A good report starts with a warm and cozy greeting
Once the hacker has found a valid bug, they can then proceed to submit a bug report by navigating to the program page and clicking on "Submit Report"
Best Practice
Before submitting a report it is considered best practice to do the following steps to improve the quality of bug reports:
Ensure that the bug is in-scope
Ensure that the bug does not violate the program policy laid out in the Rules of Engagements
Go through the bug report and ensure its clear, reproducible and properly formatted
Selecting Scope
The program may have listed multiple in-scope items out of which the hacker has to select the one which the bug falls under.
Additionally, the hacker can add an in-scope item in case a wildcard was provided in the scope restrictions of the program.
A hacker can add "docs.bugbase.in" as an item to the scope in case "*.bugbase.in" was mentioned in the rules of engagement as the scope
Vulnerable Endpoint / Affected URL (Optional)
This allows the hacker to further specify if a particular endpoint is vulnerable. Mentioning this can sometimes speed-up the triaging process by a bit.
Selecting Vulnerability Type
The hacker has to select a Vulnerability Type from a dropdown menu which has a lot of Vulnerability types grouped by OWASP Top Ten Categories.
Selecting the correct vulnerability type allows the triager to see the bug in a particular context and improves impact of the bug report.
Selecting Severity
The Severity can be selected in one of the two ways:
Severity Picker
CVSS Calculator
Whereas Severity Picker is very simple in design and a one-click process to set severity to a vulnerability, the CVSS Calculator breaks down the risk posed by the vulnerability and may be better able to define the overall severity of the vulnerability.
The Report
Title
The title should define the bug in a few words. Phrases like "Remote command Execution" and "Unauthenticated Local File Inclusion" are welcome.
It can be used to expand upon the selected Vulnerability Type in a few words.
Summary
The Summary should describe the bug in a few sentences. The characteristics of the bug like complexity, user interaction, privileges required and a brief of the impact can be provided to improve the quality of the bug report.
Proof of concept
BugBase provides a Bug Submission Template by default for every report. It can be modified by the hackers to suit their needs. It is suggested that this format be followed for all bug reports.
The more seasoned hackers can most definitely use their own format provided it is professionally written and covers all the information needed to address the bug
Attachments
A good bug report is accompanied with screenshots or a video POC if it requires chaining of exploits/bugs. Adding attachments is optional but advised so as to assist the triaging team in reproducing the bug without issues.
Vulnerability Impact
The Impact section talks about the risk posed by the bug and the situations that could happen if the bug was exploited by a malicious hacker. It can also talk about how the bug can act a base for other possible bugs. The impact section is not meant for further description of the bug.
Reviewing Report
Once the hacker has successfully filled all the sections of the bug report completely, a small pane shows them how the report looks like on the whole and would appear like once submitted.
Best Practice suggests going through the report thoroughly to see if something was missed or any other error is present.
If the hacker is not satisfied with their report and wants to amend their report at another time, the report can be saved as a draft and accessed later.
Submitting the report
Once the Hacker is satisfied with their bug report, they can submit the report by clicking on submit. Now the report will be sent to the program and will await the triage process.
Last updated
