Public cloneable() Method Without Final ('Object Hijack')

Draft Variant
Structure: Simple
Description

This vulnerability occurs when a class implements a public clone() method without declaring it final. This allows attackers to create copies of objects without invoking their constructors, potentially leaving the cloned object in an inconsistent or insecure state.

Extended Description

When a clone() method isn't marked final, subclasses can override it and bypass the original class's intended construction logic. This object hijacking technique lets an attacker create instances that skip critical initialization steps like security checks, resource allocation, or state validation, leading to unexpected behavior or security flaws. To prevent this, always declare the clone() method as final in security-sensitive classes, or consider alternative object creation patterns like copy constructors or factory methods. This ensures that object duplication follows a controlled path and maintains the object's integrity, preventing attackers from manipulating the cloning process to create malicious or unstable instances.

Common Consequences 1
Scope: IntegrityOther

Impact: Unexpected StateVaries by Context

Potential Mitigations 1
Phase: Implementation
Make the cloneable() method final.
Demonstrative Examples 2
In this example, a public class "BankAccount" implements the cloneable() method which declares "Object clone(string accountnumber)":

Code Example:

Bad
Java
java
In the example below, a clone() method is defined without being declared final.

Code Example:

Bad
Java
java
References 2
Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors
Katrina Tsipenyuk, Brian Chess, and Gary McGraw
NIST Workshop on Software Security Assurance Tools Techniques and MetricsNIST
07-11-2005
ID: REF-6
OWASP , Attack Category : Mobile code: object hijack
OWASP
ID: REF-453
Applicable Platforms
Languages:
Java : Undetermined
Modes of Introduction
Implementation
Taxonomy Mapping
  • 7 Pernicious Kingdoms
  • The CERT Oracle Secure Coding Standard for Java (2011)
  • Software Fault Patterns