CWE

Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > CWE- Individual Dictionary Definition (2.11)  
ID

CWE-478: Missing Default Case in Switch Statement

Weakness ID: 478
Abstraction: Variant
Status: Draft
Presentation Filter:
+ Description

Description Summary

The code does not have a default case in a switch statement, which might lead to complex logical errors and resultant weaknesses.

Extended Description

This flaw represents a common problem in software development, in which not all possible values for a variable are considered or handled by a given process. Because of this, further decisions are made based on poor information, and cascading failure results. This cascading failure may result in any number of security issues, and constitutes a significant failure in the system.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

C

C++

Java

.NET

+ Common Consequences
ScopeEffect
Integrity

Technical Impact: Varies by context; Alter execution logic

Depending on the logical circumstances involved, any consequences may result: e.g., issues of confidentiality, authentication, authorization, availability, integrity, accountability, or non-repudiation.

+ Demonstrative Examples

Example 1

The following does not properly check the return code in the case where the security_check function returns a -1 value when an error occurs. If an attacker can supply data that will invoke an error, the attacker can bypass the security check:

(Bad Code)
Example Language:
#define FAILED 0
#define PASSED 1
int result;
...
result = security_check(data);
switch (result) {
case FAILED:
printf("Security check failed!\n");
exit(-1);
//Break never reached because of exit()
break;
case PASSED:
printf("Security check passed.\n");
break;
}
// program execution continues...
...

Instead a default label should be used for unaccounted conditions:

(Good Code)
Example Language:
#define FAILED 0
#define PASSED 1
int result;
...
result = security_check(data);
switch (result) {
case FAILED:
printf("Security check failed!\n");
exit(-1);
//Break never reached because of exit()
break;
case PASSED:
printf("Security check passed.\n");
break;
default:
printf("Unknown error (%d), exiting...\n",result);
exit(-1);
}

This label is used because the assumption cannot be made that all possible cases are accounted for. A good practice is to reserve the default case for error handling.

Example 2

In the following Java example the method getInterestRate retrieves the interest rate for the number of points for a mortgage. The number of points is provided within the input parameter and a switch statement will set the interest rate value to be returned based on the number of points.

(Bad Code)
Example Language: Java 
public static final String INTEREST_RATE_AT_ZERO_POINTS = "5.00";
public static final String INTEREST_RATE_AT_ONE_POINTS = "4.75";
public static final String INTEREST_RATE_AT_TWO_POINTS = "4.50";
...
public BigDecimal getInterestRate(int points) {
BigDecimal result = new BigDecimal(INTEREST_RATE_AT_ZERO_POINTS);

switch (points) {
case 0:
result = new BigDecimal(INTEREST_RATE_AT_ZERO_POINTS);
break;
case 1:
result = new BigDecimal(INTEREST_RATE_AT_ONE_POINTS);
break;
case 2:
result = new BigDecimal(INTEREST_RATE_AT_TWO_POINTS);
break;
}
return result;
}

However, this code assumes that the value of the points input parameter will always be 0, 1 or 2 and does not check for other incorrect values passed to the method. This can be easily accomplished by providing a default label in the switch statement that outputs an error message indicating an invalid value for the points input parameter and returning a null value.

(Good Code)
Example Language: Java 
public static final String INTEREST_RATE_AT_ZERO_POINTS = "5.00";
public static final String INTEREST_RATE_AT_ONE_POINTS = "4.75";
public static final String INTEREST_RATE_AT_TWO_POINTS = "4.50";
...
public BigDecimal getInterestRate(int points) {
BigDecimal result = new BigDecimal(INTEREST_RATE_AT_ZERO_POINTS);

switch (points) {
case 0:
result = new BigDecimal(INTEREST_RATE_AT_ZERO_POINTS);
break;
case 1:
result = new BigDecimal(INTEREST_RATE_AT_ONE_POINTS);
break;
case 2:
result = new BigDecimal(INTEREST_RATE_AT_TWO_POINTS);
break;
default:
System.err.println("Invalid value for points, must be 0, 1 or 2");
System.err.println("Returning null value for interest rate");
result = null;
}

return result;
}
+ Potential Mitigations

Phase: Implementation

Ensure that there are no unaccounted for cases, when adjusting flow or values based on the value of a given variable. In switch statements, this can be accomplished through the use of the default label.

Phase: Implementation

In the case of switch style statements, the very simple act of creating a default case can mitigate this situation, if done correctly. Often however, the default case is used simply to represent an assumed option, as opposed to working as a check for invalid input. This is poor practice and in some cases is as bad as omitting a default case entirely.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory171Cleansing, Canonicalization, and Comparison Errors
Development Concepts699
ChildOfWeakness ClassWeakness Class398Indicator of Poor Code Quality
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class697Insufficient Comparison
Research Concepts (primary)1000
ChildOfCategoryCategory962SFP Secondary Cluster: Unchecked Status Condition
Software Fault Pattern (SFP) Clusters (primary)888
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPFailure to account for default case in switch
Software Fault PatternsSFP4Unchecked Status Condition
+ References
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Switch Statements", Page 337.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-05-27CWE Content TeamMITREInternal
updated Description, Name
2010-06-21CWE Content TeamMITREInternal
updated Demonstrative_Examples
2011-03-29CWE Content TeamMITREInternal
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-06-27CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated References, Relationships
2014-06-23CWE Content TeamMITREInternal
updated Description, Other_Notes, Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Failure to Account for Default Case in Switch
2009-05-27Failure to Use Default Case in Switch

More information is available — Please select a different filter.
Page Last Updated: May 05, 2017