WebAppSec/Filing In Bugzilla: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Created page with "=Filing a Web Security Bug 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.")
 
No edit summary
Line 1: Line 1:
=Filing a Web Security Bug 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.
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===
Begin by opening a new bug: https://bugzilla.mozilla.org/enter_bug.cgi
Most website bugs will be filed in "Other Products" at the bottom of the page.
[[Image:BugzillaProcess0.png]]
The "Websites" section under "Other" contains most sites.
[[Image:BugzillaProcess1.png|700px]]
===Selecting a Component===
Next, select a component from the list. If the website with the vulnerability is not listed, select "Other."
[[Image:BugzillaProcess2.png|800px]]
===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: [https://wiki.mozilla.org/WebAppSec/Web_App_Severity_Ratings#Rating WebAppSec Wiki]
Typically, XSS uses "Critical" and vulnerabilities that expose information are "High." Any SQL injection attacks are considered a "Blocker." Please use the ratings list to determine the exact rating for the vulnerability.
===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
===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).
===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 boxes (note that you may need to click "Show Advanced Fields" to see them all):
* Security-Sensitive Websites Bug
* Many users could be harmed by this security problem: it should be kept hidden from the public until it is resolved.
===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.

Revision as of 20:49, 20 August 2012

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

Begin by opening a new bug: https://bugzilla.mozilla.org/enter_bug.cgi

Most website bugs will be filed in "Other Products" at the bottom of the page.

BugzillaProcess0.png

The "Websites" section under "Other" contains most sites.

BugzillaProcess1.png

Selecting a Component

Next, select a component from the list. If the website with the vulnerability is not listed, select "Other."

BugzillaProcess2.png

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 "High." Any SQL injection attacks are considered a "Blocker." Please use the ratings list to determine the exact rating for the vulnerability.

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

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).

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 boxes (note that you may need to click "Show Advanced Fields" to see them all):

  • Security-Sensitive Websites Bug
  • Many users could be harmed by this security problem: it should be kept hidden from the public until it is resolved.

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.