Security/Web Bug Rotation: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(update bounty handling text)
(→‎NEW: update instructions)
Line 35: Line 35:
# Determine if the issue reported is NEW, INVALID, or DUPLICATE
# Determine if the issue reported is NEW, INVALID, or DUPLICATE
# For '''NEW''' bugs
# For '''NEW''' bugs
## Find an owner (typically a dev or the product manager) to assign the bug to, and needinfo her/him. Change status to ASSIGNED.
## CC the Security POC and Backup on the website [https://docs.google.com/spreadsheets/d/14Gp6TPAibO7UkgJTXSeOIeFNMdfDbrUXQpqRFW3tDbg/edit#gid=0 contact list]. Change status to ASSIGNED.
## Set the right '''[https://bugzilla.mozilla.org/describekeywords.cgi keywords]'''
## Set the right '''[https://bugzilla.mozilla.org/describekeywords.cgi keywords]'''
### sec-{critical,high,moderate,low,other}, see [https://wiki.mozilla.org/WebAppSec/Web_App_Severity_Ratings#Severity_Ratings severity ratings]
### sec-{critical,high,moderate,low,other}, see [https://wiki.mozilla.org/WebAppSec/Web_App_Severity_Ratings#Severity_Ratings severity ratings]
### wsec-{authentication,cookie,xss,sqli,...}, see [https://wiki.mozilla.org/WebAppSec/Web_App_Severity_Ratings#Group_Keywords vulnerability types]
### wsec-{authentication,cookie,xss,sqli,...}, see [https://wiki.mozilla.org/WebAppSec/Web_App_Severity_Ratings#Group_Keywords vulnerability types]
## Edit "Assigned To" and check the box for "Reset Assignee to default"
### If the but is sec-high or sec-critical, or if you believe the issue warrants it, cc the Site Owner and Business Owner to the bug and NEEDINFO flag them to alert them to the bug.
## Edit "Assigned To" and assign the bug to the Security POC.
# If the verification shows that the issue is invalid, close the bug as '''INVALID'''
# If the verification shows that the issue is invalid, close the bug as '''INVALID'''
# For '''DUPLICATE''' bugs, set dupe against old bug. Set keywords & whiteboard for the new duped bug
# For '''DUPLICATE''' bugs, set dupe against old bug. Set keywords & whiteboard for the new duped bug

Revision as of 18:04, 28 April 2016

Web Bug Verification

Web security bugs are reported to security@Mozilla.org mailbox or in a Bugzilla component, a member of Mozilla Security verifies the reported vulnerability before passing the bug on to developers. This verification work is shared by several members of the security team. The following pages meant to document the procedures for verification and to serve as a reminder for those "on call for the week"as to the procedures that need to be completed. In general bugs will have an attempt to verify them in approximately 1 working day.

To track bug submissions, set your bugzilla preferences to follow users "web-security@mozilla.org" and "webtools-security@mozilla.org":

Bug bounty watch.png











Rotation

Day On-call IRC handle
Monday Adam Muntner adamm
Tuesday Julien Vehent ulfr
Wednesday Simon Bennetts psiinon
Thursday Jonathan Claudius claudijd
Friday April King April

Verification process

The procedure below is performed by the on-call individual.

  1. If the issue was reported to the security@ alias, create a bug for it
  2. Determine if the issue reported is NEW, INVALID, or DUPLICATE
  3. For NEW bugs
    1. CC the Security POC and Backup on the website contact list. Change status to ASSIGNED.
    2. Set the right keywords
      1. sec-{critical,high,moderate,low,other}, see severity ratings
      2. wsec-{authentication,cookie,xss,sqli,...}, see vulnerability types
      3. If the but is sec-high or sec-critical, or if you believe the issue warrants it, cc the Site Owner and Business Owner to the bug and NEEDINFO flag them to alert them to the bug.
    3. Edit "Assigned To" and assign the bug to the Security POC.
  4. If the verification shows that the issue is invalid, close the bug as INVALID
  5. For DUPLICATE bugs, set dupe against old bug. Set keywords & whiteboard for the new duped bug

Follow up on a NEW bug until you get the assurance that it will be fixed, the urgency of which depends on the vulnerability and the target.

Bounty

  1. Bounty flags are set automatically through the Web Bounty Form.
  2. Check the Web Bounty FAQ for whether the site and service are in scope for the bounty program.
    1. If the site is not on the eligible list and the bug is not "extraordinary" please set the bug-bounty flag to "-" and needinfo flag :adamm.
  3. If a submitter requests that a bug submitted outside the automated form have a bounty flag added, set the bounty flag to "?" and needinfo :adamm.

For NEW bugs

NEW

For NEW bugs that have been verified, simply set the "sec-bounty" flag to "?" Most new eligible bugs are now submitted through the https://bugzilla.mozilla.org/form.web.bounty bounty form. For these bugs the appropriate flag will already be set.

DUPLICATE

If the bug is a duplicate of an existing bug

  1. Set "sec-bounty" flag to "-" on new bug since it was a dupe.
  2. Set the new bug blocking the appropriate metabug(s)
    • For older bugs duped against that do not have the current flags
    1. If the old bug has the attachment 'bounty non-qual' or similar then set sec-bounty- on the old bug
    2. If the old bug has the attachment 'bounty awarded X' or 'bounty paid X', then set sec-bounty+ on the old bug
    3. If no duplicate is found and the issue is not verified the bug shall be RESOLVED - INVALID and the whiteboard tag removed.