Returning a Mutable Object to an Untrusted Caller
Draft Base
Structure: Simple
Description
Sending non-cloned mutable data as a return value may result in that data being altered or deleted by the calling function.
In situations where functions return references to mutable data, it is possible that the external code which called the function may make changes to the data sent. If this data was not previously cloned, the class will then be using modified data which may violate assumptions about its internal state.
Common Consequences 1
Scope: Access ControlIntegrity
Impact: Modify Memory
Potentially data could be tampered with by another function which should not have been tampered with.
Potential Mitigations 2
Phase: Implementation
Declare returned data which should not be altered as constant or immutable.
Phase: Implementation
Clone all mutable data before returning references to it. This is the preferred mitigation. This way, regardless of what changes are made to the data, a valid copy is retained for use by the class.
Demonstrative Examples 1
This class has a private list of patients, but provides a way to see the list :
Code Example:
Bad
Java
javaWhile this code only means to allow reading of the patient list, the getPatients() method returns a reference to the class's original patient list instead of a reference to a copy of the list. Any caller of this method can arbitrarily modify the contents of the patient list even though it is a private member of the class.
References 1
The CLASP Application Security Process
Secure Software, Inc.
2005
ID: REF-18
Likelihood of Exploit
Medium
Applicable Platforms
Languages:
C : UndeterminedC++ : UndeterminedJava : UndeterminedC# : Undetermined
Modes of Introduction
Implementation
Related Weaknesses
Taxonomy Mapping
- CLASP
- The CERT Oracle Secure Coding Standard for Java (2011)
- The CERT Oracle Secure Coding Standard for Java (2011)
- SEI CERT Perl Coding Standard
- Software Fault Patterns