WebAppSec/Filing In Bugzilla
This page explains, step-by-step, how to file a web security bug in Bugzilla using all the proper flags, keywords, whitboard tags, etc.
- 1 Filing a Web Security Bug in Bugzilla
- 1.1 Selecting a Product and Component
- 1.2 Provide a Summary
- 1.3 Enter a Description
- 1.4 Setting Security Flags
- 1.5 Optional Information
- 1.6 What Happens Next?
Filing a Web Security Bug in Bugzilla
Selecting a Product and Component
Begin by opening a new bug: https://bugzilla.mozilla.org/enter_bug.cgi
Type the affected hostname (e.g. "blog.mozilla.com") into the search box at the top of the page. The box will autocomplete your search with available options. If no result is found, you can search manually or file a bug under "Other."
To file manually, most website bugs will be filed in "Other Products" at the bottom of the page.
The "Websites" section under "Other" contains most sites.
Next, select a component from the list. If the website with the vulnerability is not listed, select "Other."
Provide a Summary
Provide a descriptive summary of the bug. Sample titles include:
- XSS in getpersonas.mozilla.com ID Parameter
- mozilla.org CSRF vulnerability on Profile Page
Check the list of similar bugs that are found and try to make sure the bug has not yet been reported.
Enter a Description
Provide as much information about the bug as possible. This should include:
- A full URL of the vulnerable page
- Any accounts or user profiles used to test the vulnerability
- The vulnerable parameter if applicable
- Tests you have used to verify the issue
- The payload used if applicable
- For example, if the issue is XSS, please provide the exact XSS payload you used
- What the expected behavior is
- Any other information that could be useful in reproducing the bug
Setting Security Flags
Security flags are used to keep sensitive bugs hidden until the problem is resolved. This is done to protect our websites and users from attack during the time it takes to fix an issue. Marking a bug as security sensitive will still allow you to see updates to the bug, it will simply hide it from the public.
For website vulnerabilities, please check the following box (note that you may need to click "Show Advanced Fields" to see it):
- Many users could be harmed by this security problem: it should be kept hidden from the public until it is resolved.
If you are in the Websites group for Mozilla, you may also see another checkbox which can be selected:
- Security-Sensitive Websites Bug
Checking one of these boxes is sufficient to hide the security issue.
The following options will further help the security team respond to your bug, but are not required for a basic bug report.
For the "Version" drop-down, leave "unspecified" selected unless the vulnerability affects a specific version of Firefox. Change "Operating System" to "All" unless the vulnerability affects only one version of an OS. The same is true for "Hardware."
Selecting a Severity
For the "Severity" drop-down box, use the ratings listed on the WebAppSec Wiki here to determine a rating: WebAppSec Wiki
Typically, XSS uses "Critical" and vulnerabilities that expose information are "Major." Any SQL injection attacks are considered a "Blocker." Please use the ratings list to determine the exact rating for the vulnerability.
Please include attachments such as:
- Screenshots of the issue (such as an XSS alert box executing)
- A POC script
Please do not include attachments that explain the issue generically (for example, a YouTube video explaining what XSS is).
Keywords assist the security team in filtering and searching for bugs. Properly supplying keywords will help a bug receive the correct attention. A full list of keywords is available here: https://bugzilla-stage.mozilla.org/describekeywords.cgi but the only ones applicable to website security bugs are:
Keywords also help categorize the kind of bug (i.e. XSS, CSRF, etc). Please use the list here to determine the appropriate keywords: https://wiki.mozilla.org/Security_Severity_Ratings
Whiteboard tags are not typically used with web security vulnerabilities. Please use keywords as described above.
A URL may be provided that links to the vulnerable page.
The "Blocks" and "Depends On" options may be set if the submitted bug either blocks another bug with a known Bugzilla bug number or relies on another bug before it can be fixed. In the case of web security bugs, these options are often not set unless the bug is discovered during a security review, in which case it blocks the original review request bug.
What Happens Next?
After the bug is reported, an email alert is sent to all applicable members of the security team who have subscribed to alerts from Bugzilla. Once this email is sent, a member of the team will take a look at the bug and attempt to confirm whether it is a security risk. We may ask for more information if we are not able to replicate the issue.
Once the vulnerability is confirmed, the bug's status is changed from "Unconfirmed" to "New." We will then attempt to locate a developer who has worked on the project and ask him or her to assist us in fixing the bug. Depending on the complexity, you may get multiple emails from Bugzilla as the security team member and the developer attempt to fix the issue.
Once a fix has been developed, it often needs to progress through a development and stage environment before being pushed to production. Once the fix is running on the production environment and the vulnerability is confirmed to no longer exist, the bug will be marked Resolved -> Fixed.
This process may take anywhere from a day to a few weeks to complete. During this time, please do not file duplicate bugs as it only slows down the progress of fixing the first. If you feel a bug is not being given the attention it deserves, feel free to leave a comment on the bug asking for an update. This will re-email everyone involved and can remind us of a bug we may have forgotten.