CWE-493: Critical Public Variable Without Final Modifier

Description

The product has a critical public variable that is not final, which allows the variable to be modified to contain unexpected values.

If a field is non-final and public, it can be changed once the value is set by any function that has access to the class which contains the field. This could lead to a vulnerability if other parts of the program make assumptions about the contents of that field.

Potential Impact

Integrity

Modify Application Data

Confidentiality

Read Application Data

Demonstrative Examples

Suppose this WidgetData class is used for an e-commerce web site. The programmer attempts to prevent price-tampering attacks by setting the price of the widget using the constructor.

Bad

public final class WidgetData extends Applet {public float price;...public WidgetData(...) {this.price = LookupPrice("MyWidgetType");}}

The price field is not final. Even though the value is set by the constructor, it could be modified by anybody that has access to an instance of WidgetData.

Assume the following code is intended to provide the location of a configuration file that controls execution of the application.

Bad

public string configPath = "/etc/application/config.dat";

Bad

public String configPath = new String("/etc/application/config.dat");

While this field is readable from any function, and thus might allow an information leak of a pathname, a more serious problem is that it can be changed by any function.

Mitigations & Prevention

Implementation

Declare all public fields as final when possible, especially if it is used to maintain internal state of an Applet or of classes used by an Applet. If a field must be public, then perform all appropriate sanity checks before accessing the field from your code.

Detection Methods

Automated Static Analysis High — Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then sea

Taxonomy Mappings

7 Pernicious Kingdoms: — Mobile Code: Non-Final Public Field
CLASP: — Failure to provide confidentiality for stored data
The CERT Oracle Secure Coding Standard for Java (2011): OBJ10-J — Do not use public static nonfinal variables
Software Fault Patterns: SFP28 — Unexpected access points

Frequently Asked Questions

What is CWE-493?

CWE-493 (Critical Public Variable Without Final Modifier) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Variant-level weakness. The product has a critical public variable that is not final, which allows the variable to be modified to contain unexpected values.

How can CWE-493 be exploited?

Attackers can exploit CWE-493 (Critical Public Variable Without Final Modifier) to modify application data. This weakness is typically introduced during the Implementation phase of software development.

How do I prevent CWE-493?

Key mitigations include: Declare all public fields as final when possible, especially if it is used to maintain internal state of an Applet or of classes used by an Applet. If a field must be public, then perform all appropri

What is the severity of CWE-493?

CWE-493 is classified as a Variant-level weakness (Low-Medium abstraction). Its actual severity depends on the specific context and how the weakness manifests in your application.