User:Tritter/Working/Web Security Severity Ratings

Severity Ratings

In all cases, the severity of server and web application bugs is dependent on the critically of the service and the value of the data that could be compromised. Thus while the table below provides very broad guideliens, they cannot be directly used to determine the severity of a bug absent the consideration of the affected service.

Severity Ratings & Examples

The following items are keywords for the severity of an issue.

sec-critical
Really bad stuff.
sec-critical Examples:
  • XSS (Stored)
  • CSRF
  • Remoce Code Execution
  • Authentication Flaws (which lead to account compromise)
  • Session Management Flaws (which lead to account compromise)
sec-high
Typically, sec-high issues are exploitable web vulnerabilities that can lead to the targeted compromise of a small number of users.
sec-high Examples:
  • Cross-site Scripting (XSS)
  • 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). The lack of standard defense in depth techniques and security controls.
sec-moderate Examples:
  • Detection of arbitrary local files
  • 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
sec-low Examples:
  • Lack of proper input validation (not resulting in XSS or injection)
  • Content spoofing (non-html)

Additional Status Codes, Whiteboard Tracking Tags & Flags

Alternate Keywords

Often none of the above severity ratings apply to a bug, because it is not a vulnerability but nonetheless is security sensitive and needs to be kept private. These keywords apply to those.

Alternate Keywords & Examples
sec-other
sec-other is a bit of a catch-all bucket used for bugs that are not exploitable security issues but need to be kept confidential to protect sensitive information.
sec-other Examples:
  • XXX

A historical keyword is sec-incident, which is no longer used. sec-want, sec-audit, and sec-vector are not used for Web client bugs.

wsectype- Keywords

csectype- keywords are assigned to bugs to indicate the type of a vulnerability. Ideally these would be assigned to every vulnerability, but frequently they are not. While we request that only the security team assign sec-high and similar ratings, if you feel you can identify the type of a security bug we encourage you to classify it yourself.

Code Description
wsec-authentication Website or server authentication security issues (lockouts, password policy, etc)
wsec-authorization web/server authorization security issues
wsec-cookie Cookie related errors (HTTPOnly / Secure Flag, incorrect domain / path)
wsec-crossdomain Issue such as x-frame-options, crossdomain.xml, cross site sharing settings
wsec-crypto Crypto related items such as password hashing
wsec-csrf Cross-Site Request Forgery (CSRF) bugs in server products
wsec-disclosure Disclosure of sensitive data, personal information, etc from a web service
wsec-dos Used to denote web server Denial of Service bugs. For similar bugs in client software please use csectype-dos instead.
wsec-errorhandling Any error handling issue
wsec-impersonation Impersonation / Spoofing attacks (UI Redress, etc)
wsec-injection Injection attacks other than SQLi or XSS
wsec-input Failure to perform input validation. Most often you will probably use the xss tag instead
wsec-logging Logging issues such as requests for CEF log points.
wsec-other web/server security issues that don't fit into other categories
wsec-session Issues related to sesson management (Session fixation, etc)
wsec-sqli SQL Injection
wsec-ssrf Server Side Request Forgery (SSRF) bugs in server products. CWE-918
wsec-xss Cross-Site Scripting (XSS) bugs in server products

opsectype- Keywords

opsectype- keywords are assigned to bugs relating to Operations Security (Mozilla owned & operated severs and services)

Code Description
opsec-access The identified issue is an access violation.

Whiteboard Tags

Whiteboard Tags
Code Description Examples
sec-assigned:UserAlias depricated for sec-review? flag with alias This designates the assigned security resource that is accountable for actions to be taken on the designated item. When possible the bug will be assigned to the security contact for action. This will be used when that is not possible or practical. sec-review?:curtisk@blah.bah indicates that curtisk is the accountable party for action
[Q2] This designates a bug as being identified as a request to be done or targeted for a given operational quarter. If no year is given it is for the current year. [Q2] indicates second quarter of the current calendar year, [Q1-2013] would be used to indicate a target for an upcoming quarter that has not occurred.
[k90] This designates a bug as being part of the Kilimanjaro effort so that it can be tracked, triaged and given appropriate priority and attention.
[basecamp] This designates a bug as being part of the basecamp sub effort of the Kilimanjaro effort.
[fennec] This designates a bug as being a critical bug for the efforts around our mobile browser project. This could be combined with either the [k9o] or [basecamp] tags as a bug could be part of both.
[triage needed] Used to mark a bug for weekly triage meeting.
[pending secreview] deprecated Indicates a secreview or tasks related to said review are yet to be completed.
[start mm/dd/yyyy][target mm/dd/yyyy] This indicates that expected dates to start and complete work on a given review or security bug. [start 01/29/2013][target 02/09/2013] indicates work will start on 29-Jan and expected target for completion on 09-Feb
[completed secreview] deprecated Indicates the given secreview or related tasks have been completed
mentorship Indicates that a given bug is part of our security mentorship program. The assignee of said bug is the Mozilla mentor for such a bug.
[score:##] deprecated This indicates the relative severity score for risk rating bugs per the calculator at https://people.mozilla.com/~ckoenig/ [score:30:moderate] shows that the issue has a numerical score of 30 and a severity of moderate.
[Web] Indicates an item related to our Web properties
u= c= p= These items are used to allow bugs to be tracked by scrumbu.gs for work tracking (more info).
s= This tag is used in conjunction with the scrumbu.gs tags above to indicate which sprint a given bug has been assigned. s=13q4.1 indicates the bug is in the year 2013, 4th quarter and sprint 1. Each sprint is 2 weeks long and it's calendar dates can be tracked on scrumbu.gs

Feature Page Codes

Feature Page Codes
Code Description Examples
sec-review-needed A security review is needed for the feature, this could mean a variety of things. If there is no <username> in the notes then a full review needs to be scheduled, if a <username> is present than that person will follow-up with the feature team on whatever task is needed.
sec-review-complete The security review / actions desired have been completed. This will result in a link to the notes from security actions or a note from the assigned resource.
sec-review-active There are active tasks associated with the review that are yet to be completed in order for the review to be seen as completed. These will be captured in the "Action Items" section of the review notes.
sec-review-sched Security review tasks have been scheduled, if this is a full security review the date of the scheduled review will be present in the security notes.
sec-review-unnecessary After triage it was felt the feature needed no review or security actions.
Security health: <blank> There are no notes or status is unknown. Color: <None>
Security health: OK The tasks are on schedule or completed and are considered non-blocking. Color: Green
Security health: Blocked Some aspect of the security review has given cause to block the feature from further work or landing. The reasons will be listed in the security notes or linked to a larger review outcome for follow-up. Color: Yellow
Security health: At Risk Some aspect of the security review may cause the feature to be blocked or put the feature at risk of being off schedule.The reasons will be listed in the security notes or linked to a larger review outcome for follow-up. Color: Red
Security health: Assigned Security tasks have been assigned to a member of the team to followup. The name of this resource will be in the security notes. Color: Teal

Flags

Flags
Flag Description Settings
sec-review Security review - Requesting action from the security assurance team or showing the results of said action
Setting Description
'?' Request for the security team to review the requested bug for action
'+' Bug has been reviewed, actions are done and the security team has no further concerns at this time
'-' But has been reviewed and found to be deficient in a security metric that should be mitigated
sec-bounty Shows the status of a bug with regards to a bounty payout per our bounty guidlines
Setting Description
'?' Bug is nominated for review by the bounty committee
'+' Bug has been accepted and a payment will be made
'-' Bug does not meet criteria and a payment will not be made
sec-bounty-hof Shows the status of a bug with regards to a bounty hall of fame entry
Setting Description
'?' Bug is nominated for review by the bounty committee
'+' Bug has been accepted and an entry in the hall of fame will occur
'-' Bug does not meet criteria and a hall of fame entry will not be made