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

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)

Bugzilla Whiteboard Codes

[infrasec:auth]	Authentication (lockouts, password policy, etc)
[infrasec:access]	Access Control
[infrasec:cookie]	Cookie related errors (HTTPOnly / Secure Flag, incorrect domain / path)
[infrasec:crypto]	Crypto related items such as password hashing (use tls below for SSL items)
[infrasec:csrf]	Lack of CSRF protection
[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:osinject]	Operating system injection
[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]

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

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