Changes

Jump to: navigation, search

Security Severity Ratings

166 bytes added, 14:13, 4 May 2012
no edit summary
{{TOC right}}
Security bugs are rated by specifying "sec-<rating>" in the "Keyword" field in bugzilla. For example, a bug with a Critical security rating would be marked as "sec-critical".
 
==Severity Ratings ==
{| class="wikitable collapsible" style="width: 100%"
;'''sec-critical''': Exploitable vulnerabilities which can lead to the widespread compromise of many users.
{| class="wikitable collapsible collapsed" style="width: 100%"! ''Examples:''|-|
* Overflows resulting in native code execution
* JavaScript injection into browser chrome
** Authentication Flaws (which lead to account compromise)
** Session Management Flaws (which lead to account compromise)
|}
;'''sec-high''': Obtain confidential data from other sites the user is visiting or the local machine, or inject data or code into those sites, requiring no more than normal browsing actions. Indefinite DoS of the user's system, requiring OS reinstallation or extensive cleanup. Exploitable web vulnerabilities that can lead to the targeted compromise of a small number of users.
{| class="wikitable collapsible collapsed" style="width: 100%"! ''Examples:''|-|
* Cross-site Scripting (XSS)
* Theft of arbitrary files from local system
* XSS (Reflected)
*Failure to use TLS where needed to ensure confidential/security
|}
;'''sec-moderate''': Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. Disclosure of sensitive information that represents a violation of privacy but by itself does not expose the user or organization to immediate risk. The vulnerability combined with another moderate vulnerability could result in an attack of high or critical severity (aka stepping stone). Indefinite application Denial of Service (DoS) via corruption of state, requiring application re-installation or temporary DoS of the user's system, requiring reboot. The lack of standard defense in depth techniques and security controls.
{| class="wikitable collapsible collapsed" style="width: 100%"! ''Examples:''|-|
* Disclosure of OS username
* Disclosure of browser cache salt
* Missing Additional Security Controls (x-frame options, SECURE/HTTPOnly flags, etc)
* Error Handling Issues
|}
;'''sec-low''': Minor security vulnerabilities such as leaks or spoofs of non-sensitive information. Missing best practice security controls
{| class="wikitable collapsible collapsed" style="width: 100%"! ''Examples:''|-|
* Detection of previous visit to a specific site
* Identification of users by profiling browsing behavior.
* Lack of proper input validation (not resulting in XSS or injection)
* Content spoofing (non-html)
|}
;'''sec-other''': Bugs that may not be exploitable security issues but are kept confidential to protect sensitive information. Bugs that contain sensitive information about the bug submitter or another user Bugs that are related to security issues currently unfixed in Mozilla products or other products
{| class="wikitable collapsible collapsed" style="width: 100%"! ''Examples:''|-|
* Flaws we need to track that are not in our code base
|}
;'''Mitigating Circumstances''':
If there are mitigating circumstances that severely reduce the effectiveness of the exploit, then the exploit could be reduced by one level of severity. Examples of mitigating circumstances include difficulty in reproducing due to very specific timing or load order requirements, complex or unusual set of actions the user would have to take beyond normal browsing behaviors, or unusual software configuration.
As a rough guide, to be considered for reduction in severity an exploit should execute successfully less than 10% of the time. If measures can be taken to improve the reliability of the exploit to over 10% (by combining it with other existing bugs or techniques), then it should not be considered to be mitigated.
 
 
|}
Canmove, confirm, emeritus
2,776
edits

Navigation menu