CWE-493: Critical Public Variable Without Final Modifier

What is Critical Public Variable Without Final Modifier?

• Overview: This vulnerability occurs when a public variable in a class is not declared as final, allowing it to be modified by any code with access to the class after its initial setting. This can lead to unexpected behavior or security issues if the variable's value is assumed to remain constant.

• Exploitation Methods:

• Attackers or untrusted code can modify the variable to inject unexpected or malicious values.
• Common attack patterns include manipulating the variable to disrupt program logic, cause incorrect data processing, or induce application crashes.

• Security Impact:

• Direct consequences include unauthorized changes to critical variables, leading to altered application behavior.
• Potential cascading effects may involve data corruption, security bypasses, or application instability.
• Business impact could manifest as service outages, data integrity issues, or exploitation of further vulnerabilities.

• Prevention Guidelines:

• Specific code-level fixes include declaring public variables as final to prevent modification after initialization.
• Security best practices involve minimizing the use of public variables and employing encapsulation to control access.
• Recommended tools and frameworks include static code analysis tools to detect and flag public non-final variables during development.

Corgea can automatically detect and fix Critical Public Variable Without Final Modifier in your codebase. [Try Corgea free today](https://corgea.app).

Technical Details

Likelihood of Exploit: High

Affected Languages: Java, C++

Affected Technologies: Not specified

Mobile code, such as a Java Applet, is code that is transmitted across a network and executed on a remote machine. Because mobile code developers have little if any control of the environment in which their code will execute, special security concerns become relevant. One of the biggest environmental threats results from the risk that the mobile code will run side-by-side with other, potentially malicious, mobile code. Because all of the popular web browsers execute code from multiple sources together in the same JVM, many of the security guidelines for mobile code are focused on preventing manipulation of your objects' state and behavior by adversaries who have access to the same virtual machine where your program is running.

Vulnerable Code Example

// This Java class demonstrates a critical vulnerability where a public variable can be modified externally.
public class ConfigManager {
    // This is a critical configuration variable that is public and non-final
    // It can be modified from outside the class, potentially leading to security issues
    public String apiKey; // Vulnerable: public and mutable

    public ConfigManager(String apiKey) {
        this.apiKey = apiKey;
    }
    
    // Other methods...
}

How to fix Critical Public Variable Without Final Modifier?

To fix the vulnerability caused by a public variable that can be modified externally, you should follow these security principles:

1. Encapsulation: Make the variable private to prevent direct access from outside the class.
2. Immutability: Use the final modifier to ensure the variable cannot be reassigned once initialized.
3. Controlled Access: Provide a public getter method if read access is necessary, preventing modification.

By making these changes, you ensure that the critical variable cannot be altered, reducing the risk of unintended or malicious modifications.

Fixed Code Example

// This Java class demonstrates a secure way to handle critical configuration variables.
public class ConfigManager {
    // The apiKey is now private and final, ensuring it cannot be modified once set
    private final String apiKey; // Secure: private and immutable

    public ConfigManager(String apiKey) {
        this.apiKey = apiKey;
    }

    // Provides read-only access to the apiKey
    public String getApiKey() { // This method ensures controlled access to the apiKey
        return apiKey;
    }

    // Other methods...
}

In the fixed code, the apiKey is marked as private and final, preventing external modification and ensuring its value remains constant once set. The addition of a getter method (getApiKey) allows controlled access to the value, aligning with the principles of encapsulation and immutability. This approach mitigates the risk of unintended or malicious modifications to critical configuration data.