WebAppSec/Web App Severity Ratings: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
(Redirected page to Security Severity Ratings)
 
(5 intermediate revisions by 3 users not shown)
Line 1: Line 1:
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.
#REDIRECT [[Security_Severity_Ratings]]
 
==Web Application Severity Ratings Table==
'''This is used for the [ws:xxxx] whiteboard tab'''
 
{| border="1"
|-
! scope="col" | Severity
! scope="col" | Description
! scope="col" | Examples
|-
! scope="row" | Critical
| valign="top" align="left" |
Exploitable vulnerabilities which can lead to the widespread compromise of many users.<br>
 
| valign="top" align="left" |
XSS (Stored)
 
CSRF
 
Code Injection
 
Authentication Flaws <br>
(which lead to account compromise)
 
Session Management Flaws  <br>
(which lead to account compromise)
 
|-
! scope="row" | High 
| valign="top" align="left" |
Exploitable vulnerabilities that can lead to the targeted compromise of a small number of users.<br>
 
| valign="top" align="left" |
XSS (Reflected)
 
Failure to use TLS where needed to ensure confidential/security
 
|-
! scope="row" | Moderate 
| valign="top" align="left" |
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.
 
| valign="top" align="left" |
Missing Additional Security Controls (x-frame options, SECURE/HTTPOnly flags, etc)
 
Error Handling Issues
 
|-
! scope="row" | Low 
| valign="top" align="left" |
Missing best practice security controls
 
| valign="top" align="left" |
Lack of proper input validation (not resulting in XSS or injection)
 
Content spoofing (non-html)
|-
! scope="row" | None
| valign="top" align="left" |
Not an exploitable issue, usually an enhancement, etc.
 
| valign="top" align="left" |
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'''
 
{| cellspacing="1" cellpadding="1" border="1" style="width: 564px; height: 417px;"
|-
| [infrasec:access]<br>
| Access Control<br>
|-
| [infrasec:auth]<br>
| Authentication (lockouts, password policy, etc)<br>
|-
| [infrasec:bestpractice]<br>
| Issues that are not exploitable, but increase attack surface (documentation, example scripts, etc)<br>
|-
| [infrasec:config]<br>
| Server configuration related issues<br>
|-
| [infrasec:cookie]<br>
| Cookie related errors (HTTPOnly / Secure Flag, incorrect domain / path)<br>
|-
| [infrasec:crossdomain]<br>
| 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&nbsp;items)
|-
| [infrasec:csrf]<br>
| Lack of CSRF protection<br>
|-
| [infrasec:disclosure]<br>
| Disclosure of sensitive data, personal information, etc<br>
|-
| [infrasec:dos]<br>
| Denial of service vulnerabilities due to memory exhaustion or processor exhaustion<br>
|-
| [infrasec:errorhandle]<br>
| Any error handling issue<br>
|-
| [infrasec:input]<br>
| Failure to perform input validation. Most often you will probably use the xss tag instead.<br>
|-
| [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]<br>
| Operating system injection<br>
|-
| [infrasec:sqlinject]<br>
| SQL injection<br>
|-
| [infrasec:tls]<br>
| Transport security issues (e.g. lack of SSL&nbsp;or improper config) <br>
|-
| [infrasec:xss]<br>
| Any failure of output encoding is essentially XSS<br>
|}
 
For security bugs discovered during QA we will use '''[infrasec-qa:whatever]'''
 
Example:
 
[infrasec-qa:xss]<br>
 
[ws:need triage] - tag used for needing review<br>
 
==Security Group Settings==
Security Sensitive Bugs should have the following groups set depending upon the product. <br>
'''Product: Websites'''<br/>
View Group: Security-Sensitive Websites Bug<br/>
Use: Any vulnerability in the web code.<br/>
<br/>
'''Product: mozilla.org'''<br/>
View Group: Infrastructure-related Bugs<br/>
Use: These types of bugs should be against stuff within the<br/>
infrastructure. Shouldn't be code or vulnerabilities in the web code.<br/>
<br/>
'''Product: Mozilla Services'''<br/>
View Group: Security-Sensitive Client Services Bug<br/>
Use: Anything with the services side of the Sync including Infrasec issues.<br/>
 
== 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.
<nowiki>Insert non-formatted text here</nowiki>
 
== Whiteboard Tags for Security Reviews ==
These are the work flow tags for the web security review process.<br>
 
Status Tags
* '''[pending secreview]''' - pending to be reviewed
* '''[in-progress secreview]''' - it is currently being worked on
* '''[completed secreview]''' - review completed
<br>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.

Latest revision as of 21:20, 21 August 2012

Redirect to:

Retrieved from "https://wiki.allizom.org/index.php?title=WebAppSec/Web_App_Severity_Ratings&oldid=462956"