WebAppSec/Filing In Bugzilla: Difference between revisions
(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: | ||
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.
The "Websites" section under "Other" contains most sites.
Selecting a Component
Next, select a component from the list. If the website with the vulnerability is not listed, select "Other."
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.