Security/Web Bug Rotation

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":

Rotation

Day	On-call	Slack handle
Monday - Friday	Frida Kiriakos	Frida

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.
   2. Change status to ASSIGNED. Edit "Assigned To" and assign the bug to the Security POC.
   3. Needinfo flag the Security POC and their backup.
   4. 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 bug is rated sec-high or sec-critical, or if you believe the issue warrants it, cc the Site Owner and Business Owner to the bug, cc and needinfo flag them.
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.

Vulnerability Mitigation process

When the reported vulnerability is mitigated, the engineer that did the work should change the bug status from NEW to FIXED. The engineer or bug bounty triager should then add a comment to the bug so the reporter knows what happens next. That comment should be

Thanks very much for reporting this issue to us. Now that the issue is fixed, the bug bounty team will be reviewing your report over the upcoming weeks to make a determination of what if any award Mozilla will be granting for this report. It may take up to 3 weeks but know that we've not forgotten this ticket, we have a tracking system and a review cadence that will ensure that all potentially bounty eligible reports get reviewed and acted on.

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 note that in the whiteboard field (e.g. "[bounty-ineligible site]")
3. If a submitter requests that a bug submitted outside the automated form have a bounty flag added, set the bounty flag to "?"

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 (as long as it is duped to an OLDER bug).
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.