CWE-766: Critical Data Element Declared Public

Description

The product declares a critical variable, field, or member to be public when intended security policy requires it to be private.

This issue makes it more difficult to maintain the product, which indirectly affects security by making it more difficult or time-consuming to find and/or fix vulnerabilities. It also might make it easier to introduce vulnerabilities.

Potential Impact

Integrity, Confidentiality

Read Application Data, Modify Application Data

Other

Reduce Maintainability

Demonstrative Examples

The following example declares a critical variable public, making it accessible to anyone with access to the object in which it is contained.

Bad

public: char* password;

Instead, the critical data should be declared private.

Good

private: char* password;

Even though this example declares the password to be private, there are other possible issues with this implementation, such as the possibility of recovering the password from process memory (CWE-257).

The following example shows a basic user account class that includes member variables for the username and password as well as a public constructor for the class and a public method to authorize access to the user account.

Bad

#define MAX_PASSWORD_LENGTH 15#define MAX_USERNAME_LENGTH 15
                     class UserAccount{
                        public:
                              UserAccount(char *username, char *password){if ((strlen(username) > MAX_USERNAME_LENGTH) ||(strlen(password) > MAX_PASSWORD_LENGTH)) {ExitError("Invalid username or password");}strcpy(this->username, username);strcpy(this->password, password);}
                           
                           
                           int authorizeAccess(char *username, char *password){
                              if ((strlen(username) > MAX_USERNAME_LENGTH) ||(strlen(password) > MAX_PASSWORD_LENGTH)) {ExitError("Invalid username or password");}
                                 // if the username and password in the input parameters are equal to
                                 
                                 
                                 // the username and password of this account class then authorize access
                                 if (strcmp(this->username, username) ||strcmp(this->password, password))return 0;
                                 
                                 // otherwise do not authorize access
                                 elsereturn 1;
                              
                           }
                           char username[MAX_USERNAME_LENGTH+1];char password[MAX_PASSWORD_LENGTH+1];
                     };

However, the member variables username and password are declared public and therefore will allow access and changes to the member variables to anyone with access to the object. These member variables should be declared private as shown below to prevent unauthorized access and changes.

Good

class UserAccount{public:...
                     
                     private:char username[MAX_USERNAME_LENGTH+1];char password[MAX_PASSWORD_LENGTH+1];};

Mitigations & Prevention

Implementation

Data should be private, static, and final whenever possible. This will assure that your code is protected by instantiating early, preventing access, and preventing tampering.

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

Real-World CVE Examples

CVE ID	Description
CVE-2010-3860	variables declared public allow remote read of system properties such as user name and home directory.

Taxonomy Mappings

CLASP: — Failure to protect stored data from modification
The CERT Oracle Secure Coding Standard for Java (2011): OBJ01-J — Declare data members as private and provide accessible wrapper methods
Software Fault Patterns: SFP28 — Unexpected access points
OMG ASCMM: ASCMM-MNT-15 —

Frequently Asked Questions

What is CWE-766?

CWE-766 (Critical Data Element Declared Public) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Base-level weakness. The product declares a critical variable, field, or member to be public when intended security policy requires it to be private.

How can CWE-766 be exploited?

Attackers can exploit CWE-766 (Critical Data Element Declared Public) to read application data, modify application data. This weakness is typically introduced during the Implementation phase of software development.

How do I prevent CWE-766?

Key mitigations include: Data should be private, static, and final whenever possible. This will assure that your code is protected by instantiating early, preventing access, and preventing tampering.

What is the severity of CWE-766?

CWE-766 is classified as a Base-level weakness (Medium abstraction). It has been observed in 1 real-world CVEs.