CWE-500: Public Static Field Not Marked Final

What is Public Static Field Not Marked Final?

• Overview: This vulnerability occurs when a public static field in a class is not declared as final, allowing it to be modified by any class in the application, leading to unexpected behavior or security issues.

• Exploitation Methods:

• Attackers can modify these public static fields directly, changing the state of the application in unanticipated ways.
• Common attack patterns include unauthorized alteration of application behavior and state, leading to data corruption or leakage.

• Security Impact:

• Direct consequences include unauthorized changes to application data and behavior.
• Potential cascading effects involve data integrity issues, unintended side effects, or application crashes.
• Business impact may involve loss of data integrity, breach of confidentiality, and potential reputational damage.

• Prevention Guidelines:

• Specific code-level fixes include marking public static fields as final to prevent modification.
• Security best practices involve using private fields with controlled access through getter methods.
• Recommended tools and frameworks include static code analysis tools to detect and highlight such vulnerabilities.

Corgea can automatically detect and fix Public Static Field Not Marked Final in your codebase. [Try Corgea free today](https://corgea.app).

Technical Details

Likelihood of Exploit: High

Affected Languages: C++, Java

Affected Technologies: Not specified

When a field is declared public but not final, the field can be read and written to by arbitrary Java code.

Vulnerable Code Example

C++ Example

// Vulnerable code demonstrating CWE-500: Public Static Field Not Marked as Final
#pragma once

class Configuration {
public:
    // This public static field can be modified by any code that has access to this header,
    // which could lead to unexpected behavior or security vulnerabilities.
    static int maxConnections; // Public static field
};

// Default value for the static field
#include "Configuration.h"

int Configuration::maxConnections = 100; // Initialization of the public static field

Explanation

In the vulnerable code example, maxConnections is declared as a public static field. This means any code with access to the Configuration class can modify maxConnections, potentially leading to unexpected behavior or security issues if the value is critical for application behavior.

How to fix Public Static Field Not Marked Final?

To fix this vulnerability, the public static field should be encapsulated to prevent direct modification. In C++, while there is no final keyword, similar functionality can be achieved by:

1. Using Private Static Fields: Make the static field private to prevent direct access from outside the class.
2. Providing a Public Getter Method: Allow controlled access to the value through a public getter method.
3. Avoiding a Public Setter Method: Do not provide a setter method if the value should remain constant after initialization, ensuring immutability.

This approach prevents unauthorized code from altering important configuration values, which might be critical for maintaining system integrity and security.

Fixed Code Example

#pragma once

class Configuration {
public:
    // Public method to get the static field's value
    static int getMaxConnections(); // Getter for the static field

private:
    // Private static field, preventing direct access and modification
    static int maxConnections; // Private static field
};

// Proper encapsulation of the static field
#include "Configuration.h"

// Initialize the static field
int Configuration::maxConnections = 100; // Initialization of the private static field

// Implementation of the getter method
int Configuration::getMaxConnections() {
    return maxConnections; // Controlled access to the field value
}

Explanation

In the fixed code, the maxConnections field is made private, and access is controlled through the getMaxConnections() method. This ensures that the field cannot be altered unexpectedly, thus mitigating the CWE-500 vulnerability. The encapsulation provides a controlled way to access the value while preventing unauthorized modifications, adhering to best practices for C++ and enhancing the security of the application.