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.

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.

Optional Information

The following options will further help the security team respond to your bug, but are not required for a basic bug report.

Additional Information

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.

Attachments

Please include attachments such as:

• Screenshots of the issue (such as an XSS alert box executing)
• A POC script
• A demo video

Please do not include videos or attachments that explain the issue generically (for example, a YouTube video explaining what XSS is).

Adding Keywords

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:

• sec-critical
• sec-high
• sec-moderate
• sec-low
• sec-other

Whiteboard Tags

As with keywords, whiteboard tags assist the security team is sorting and categorizing security bugs. This page lists the available whiteboard tags: https://wiki.mozilla.org/WebAppSec/Web_App_Severity_Ratings

Be sure to include both the severity tag as well as the infrasec tag.

As an example, a reflected XSS vulnerability would have whiteboard tags: [ws:high][infrasec:xss]

Additional Options

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.