The product uses the singleton pattern when creating a resource within a multithreaded environment.
Extended Description
The use of a singleton pattern may not be thread-safe.
ThreatScore
Threat Mapped score: 1.8
Industry: Finiancial
Threat priority: P4 - Informational (Low)
Observed Examples (CVEs)
No observed examples available.
Related Attack Patterns (CAPEC)
N/A
Attack TTPs
N/A
Modes of Introduction
Phase
Note
Implementation
N/A
Common Consequences
Impact: Other, Modify Application Data — Notes:
Potential Mitigations
Architecture and Design: Use the Thread-Specific Storage Pattern. See References. (N/A)
Implementation: Do not use member fields to store information in the Servlet. In multithreading environments, storing user data in Servlet member fields introduces a data access race condition. (N/A)
Implementation: Avoid using the double-checked locking pattern in language versions that cannot guarantee thread safety. This pattern may be used to avoid the overhead of a synchronized call, but in certain versions of Java (for example), this has been shown to be unsafe because it still introduces a race condition (CWE-209). (Limited)
Applicable Platforms
Java (N/A, Undetermined)
C++ (N/A, Undetermined)
Demonstrative Examples
Intro: This method is part of a singleton pattern, yet the following singleton() pattern is not thread-safe. It is possible that the method will create two objects instead of only one.
Body: Consider the following course of events:
private static NumberConverter singleton; public static NumberConverter get_singleton() { if (singleton == null) { singleton = new NumberConverter(); } return singleton; }