Access to Critical Private Variable via Public Method
The software defines a public method that reads or modifies a private variable.
If an attacker modifies the variable to contain unexpected values, this could violate assumptions from other parts of the code. Additionally, if an attacker can read the private variable, it may expose sensitive information or make it easier to launch further attacks.
The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.
Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.
The following example declares a critical variable to be private, and then allows the variable to be modified by public methods.
The following example could be used to implement a user forum where a single user (UID) can switch between multiple profiles (PID).
The programmer implemented setPID with the intention of modifying the PID variable, but due to a typo. accidentally specified the critical variable UID instead. If the program allows profile IDs to be between 1 and 10, but a UID of 1 means the user is treated as an admin, then a user could gain administrative privileges as a result of this typo.
This category identifies Software Fault Patterns (SFPs) within the Exposed Data cluster (SFP23).
Weaknesses in this category are related to improper assignment or handling of permissions.
This view (slice) covers all the elements in CWE.
This view (slice) lists weaknesses that can be introduced during implementation.
This view (slice) lists weaknesses that can be introduced during design.