Missing Default Case in Switch Statement

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


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.

Demonstrations

The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.

Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.

Example One

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:

#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:

#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 Two

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.

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.

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;

}

See Also

CISQ Quality Measures - Maintainability

Weaknesses in this category are related to the CISQ Quality Measures for Maintainability. Presence of these weaknesses could reduce the maintainability of the software.

Bad Coding Practices

Weaknesses in this category are related to coding practices that are deemed unsafe and increase the chances that an exploitable vulnerability will be present in the ap...

SFP Secondary Cluster: Unchecked Status Condition

This category identifies Software Fault Patterns (SFPs) within the Unchecked Status Condition cluster (SFP4).

Comprehensive CWE Dictionary

This view (slice) covers all the elements in CWE.

CWE Cross-section

This view contains a selection of weaknesses that represent the variety of weaknesses that are captured in CWE, at a level of abstraction that is likely to be useful t...

Weaknesses Introduced During Implementation

This view (slice) lists weaknesses that can be introduced during implementation.


Common Weakness Enumeration content on this website is copyright of The MITRE Corporation unless otherwise specified. Use of the Common Weakness Enumeration and the associated references on this website are subject to the Terms of Use as specified by The MITRE Corporation.