201 reads New Story

Code Smell 282 - Bad Defaults and How to Fix Them

by Maximiliano ContieriDecember 2nd, 2024

Too Long; Didn't Read

Treat unknown responses as unauthorized, not as valid.

featured image - Code Smell 282 - Bad Defaults and How to Fix Them

Defaults Can Sink You

TL;DR: Treat unknown responses as unauthorized, not as valid.

Problems

Security risks
Ignoring unknown cases
Error Misinterpretation
Defaulting to valid states
Mismatch Authorizations
Failing to log events
Exploitation Potential

Solutions

Validate all responses against a closed set of known codes.
Default (and unknown) to unauthorized or Remove Defaults.
Log every mismatched or unexpected case for analysis.
Test with edge scenarios.
Synchronize response pools with processors regularly to avoid outdated codes.
Focus on security making it a shift left process.
Design systems with change resilience to handle evolving scenarios.

Context

Today is computer security day and every programmer needs to acknowledge its responsibility.

Imagine an application handling sales that relies on response pools from credit card processors to handle transactions.

Each credit card processor provides predefined response codes for various situations, such as insufficient balance or expired cards.

The issue begins when a processor adds a new response code for denied transactions but doesn't notify the platform.

The application doesn't recognize the new code, defaults to treating it as "not found," and authorizes the purchase.

Users notice this flaw and exploit it to make unauthorized purchases.

The platform's revenue plummets, leading to bankruptcy.

Sample Code

Wrong

String response = paymentProcessor.authorize(cardDetails);

switch (response) {
    case "DECLINED_INSUFFICIENT_FUNDS":
        // Handle insufficient funds
        break;
    case "DECLINED_EXPIRED_CARD":
        // Handle expired card
        break;
    default:
        // Authorize purchase
        break;
}

Right

String response = paymentProcessor.authorize(cardDetails);

switch (response) {
    case "APPROVED":
        // Authorize purchase
        break;
    case "DECLINED_INSUFFICIENT_FUNDS":
        // Handle insufficient funds
        break;
    case "DECLINED_EXPIRED_CARD":
        // Handle expired card
        break;
    case "DECLINED_NEW_REASON":
        // Handle new declined reason
        break;
    default:
        // Reject purchase (default case for unknown responses)
        break;
}

Detection

[x]Manual

You can detect this smell by reviewing error-handling logic.

Check if the system logs and denies unrecognized cases.

Automated tests can help identify if new or unexpected inputs default to valid actions.

Static analysis tools can help by flagging potentially incomplete error handling.

Level

[x]Intermediate

Why Bijection Is Important

It's critical to maintain a one-to-one correspondence between your application's internal representation of payment processor responses and the actual codes returned by the processor.

When you break the Bijection, you create a mismatch.

The application interprets unknown codes incorrectly, leading to unexpected behavior, security holes, and potentially disastrous business consequences.

AI Generation

AI tools can create this smell if you don't specify how to handle unknown cases.

For example, generic error handling might default to benign outcomes like "not found" or "success."

AI Detection

AI generators can fix this smell when you instruct them to treat unknown cases as unauthorized and emphasize logging and testing unexpected scenarios.