WebAppSec/Web App Severity Ratings

Web application security bugs are rated by specifying [ws:<rating>] in the "Whiteboard" field in Bugzilla. For example, a bug with a Critical severity rating would be marked as [ws:critical]. The infrastructure security group utilizes these codes to do their tracking and triage. The purpose of this is to have a common and understood system for tracking bugs and to provide easy metrics.

Web Application Severity Ratings Table

This is used for the [ws:xxxx] whiteboard tab

Severity	Description	Examples
critical	Exploitable vulnerabilities which can lead to the widespread compromise of many users.	XSS (Stored) CSRF Code Injection Authentication Flaws (which lead to account compromise) Session Management Flaws (which lead to account compromise)
high	Exploitable vulnerabilities that can lead to the targeted compromise of a small number of users.	XSS (Reflected) Failure to use TLS where needed to ensure confidential/security
moderate	Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. The lack of standard defense in depth techniques and security controls.	Missing Additional Security Controls (x-frame options, SECURE/HTTPOnly flags, etc) Error Handling Issues
low	Missing best practice security controls	Lack of proper input validation (not resulting in XSS or injection) Content spoofing (non-html)
none	Not an exploitable issue, usually an enhancement, etc.	Periodic request to change a system key for password hashing Implementing a new feature to support other security processes

Bugzilla Whiteboard Codes

This is used for the [infrasec:xxxx] whiteboard tab

[infrasec:access]	Access Control
[infrasec:auth]	Authentication (lockouts, password policy, etc)
[infrasec:bestpractice]	Issues that are not exploitable, but increase attack surface (documentation, example scripts, etc)
[infrasec:config]	Server configuration related issues
[infrasec:cookie]	Cookie related errors (HTTPOnly / Secure Flag, incorrect domain / path)
[infrasec:crossdomain]	Issue such as x-frame-options, crossdomain.xml, cross site sharing settings
[infrasec:crypto]	Crypto related items such as password hashing (use tls below for SSL items)
[infrasec:csrf]	Lack of CSRF protection
[infrasec:disclosure]	Disclosure of sensitive data, personal information, etc
[infrasec:dos]	Denial of service vulnerabilities due to memory exhaustion or processor exhaustion
[infrasec:errorhandle]	Any error handling issue
[infrasec:input]	Failure to perform input validation. Most often you will probably use the xss tag instead.
[infrasec:logging]	Logging issues such as requests for CEF log points.
[infrasec:nsr]	Indicates a bug filed by infrasec, but is not security related.
[infrasec:osinject]	Operating system injection
[infrasec:session]	Issues related to sesson management (Session fixation, etc)
[infrasec:sqlinject]	SQL injection
[infrasec:tls]	Transport security issues (e.g. lack of SSL or improper config)
[infrasec:xss]	Any failure of output encoding is essentially XSS

For security bugs discovered during QA we will use [infrasec-qa:whatever]

Example:

[infrasec-qa:xss]

[ws:need triage] - tag used for needing review

Security Group Settings

Security Sensitive Bugs should have the following groups set depending upon the product.
Product: Websites
View Group: Security-Sensitive Websites Bug
Use: Any vulnerability in the web code.

Product: mozilla.org
View Group: Infrastructure-related Bugs
Use: These types of bugs should be against stuff within the
infrastructure. Shouldn't be code or vulnerabilities in the web code.

Product: Mozilla Services
View Group: Security-Sensitive Client Services Bug
Use: Anything with the services side of the Sync including Infrasec issues.

Rating

This is used for the Bugzilla importance rating dropdown box

Vulnerabilities discovered either by environmental evaluation, vulnerability scanning or community member will be resolved based on the criticality and impact of the vulnerability. Vulnerabilities should follow the severity matrix in order to properly prioritize the remediation and filling within Bugzilla.

Severity Matrix

• Blocker
  • Anything which is easily exploitable or reproducible and/or we are seeing active attempts to exploit.
  • Anything which has a high impact to Mozilla should also be considered.
  • Examples
    • SQL injection or Injection Flaws and Remote File Inclusion (RFI)
    • Anything which has been publicized as a 0day which falls into the 'Critical' category.
• Critical
  • Vulnerabilities which are exploitable and/or hard to reproduce.
  • We are also not seeing these being actively exploited or have another means to protect against a vulnerability.
  • Examples
    • XSS
    • CSRF and Authentication or token handling issues
• Major
  • Vulnerabilities which have a slightly less degree of impact compared to Critical.
  • Examples
    • Content Spoofing
    • Information Disclosure or Error Handling
• Normal
  • Internal vulnerability with a low likelihood of being remotely exploitable.

All confirmed vulnerabilities with the infrastructure should be filed as a bug under the Infrastructure Security Group and will be marked as either “Infrastructure Related" or "Security-Sensitive.” This will ensure that the bug isn't disclosed to the public and will be the initial stance on all events and vulnerabilities until a proper review of the bug is performed. Insert non-formatted text here

Whiteboard Tags for Security Reviews

These are the work flow tags for the web security review process.

Status Tags

• [pending secreview] - pending to be reviewed
• [in-progress secreview] - it is currently being worked on
• [completed secreview] - review completed

Waiting on tags

• [waiting on code complete] - waiting for the code to be completed
• [waiting on infra setup] - waiting on infrastructure to be setup

Opening Web Security Bugs

This describes the process flow within bugzilla for resolving and publicly opening up a security bug (e.g. removing security group flag).

• A bug is marked RESOLVED:FIXED when code has been created to address the security issue and someone has inspected this code to ensure it is correct. This code is likely deployed in a testing environment. At this point the code fix is not in production.
• A bug is marked VERIFIED after QA or InfraSec have verified that the code is loaded on the production server and operating as intended.

Security bugs should only be opened publicly after they reach the VERIFIED state.

Opening a bug (e.g removing the secure flag) that is RESOLVED:FIXED may expose production servers to the identified security issue since the fix has not been deployed and tested on the production server.