CWE-642: External Control of Critical State Data
The product stores security-critical state information about its users, or the product itself, in a location that is accessible to unauthorized actors.
View on MITREExtended Description
If an attacker can modify the state information without detection, then it could be used to perform unauthorized actions or access unexpected resources, since the application programmer does not expect that the state can be changed. State information can be stored in various locations such as a cookie, in a hidden web form field, input parameter or argument, an environment variable, a database record, within a settings file, etc. All of these locations have the potential to be modified by an attacker. When this state information is used to control security or determine resource usage, then it may create a vulnerability. For example, an application may perform authentication, then save the state in an "authenticated=true" cookie. An attacker may simply create this cookie in order to bypass the authentication.
Technical Details
- Structure
- Simple
Applicable To
Security Consequences
Scope
Impact
An attacker could potentially modify the state in malicious ways. If the state is related to the privileges or level of authentication that the user has, then state modification might allow the user to bypass authentication or elevate privileges.
Scope
Impact
The state variables may contain sensitive information that should not be known by the client.
Scope
Impact
By modifying state variables, the attacker could violate the application's expectations for the contents of the state, leading to a denial of service due to an unexpected error condition.
Mitigation Strategies
Phase
Description
Understand all the potential locations that are accessible to attackers. For example, some programmers assume that cookies and hidden form fields cannot be modified by an attacker, or they may not consider that environment variables can be modified before a privileged program is invoked.
Phase
Description
Store state information on the server side only. Ensure that the system definitively and unambiguously keeps track of its own state and user state and has rules defined for legitimate state transitions. Do not allow any application user to affect state directly in any way other than through legitimate actions leading to state transitions.
Phase
Description
Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible.
Phase
Description
Use dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.
Phase
Description
Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.
Detection Methods
No detection method information available for this CWE.
Code Examples & CVEs
Demonstrative Examples
In the following example, an authentication flag is read from a browser cookie, thus allowing for external control of user state data.
The following code uses input from an HTTP request to create a file name. The programmer has not considered the possibility that an attacker could provide a file name such as "../../tomcat/conf/server.xml", which causes the application to delete one of its own configuration files (CWE-22).
The following code uses input from a configuration file to determine which file to open and echo back to the user. If the program runs with privileges and malicious users can change the configuration file, they can use the program to read any file on the system that ends with the extension .txt.
This program is intended to execute a command that lists the contents of a restricted directory, then performs other actions. Assume that it runs with setuid privileges in order to bypass the permissions check by the operating system.
This code may look harmless at first, since both the directory and the command are set to fixed values that the attacker can't control. The attacker can only see the contents for DIR, which is the intended program behavior. Finally, the programmer is also careful to limit the code that executes with raised privileges.
Observed CVE Examples (13)
Mail client stores password hashes for unrelated accounts in a hidden form field.
View DetailsPrivileged program trusts user-specified environment variable to modify critical configuration settings.
View DetailsTelnet daemon allows remote clients to specify critical environment variables for the server, leading to code execution.
View DetailsUntrusted search path vulnerability through modified LD_LIBRARY_PATH environment variable.
View DetailsUntrusted search path vulnerability through modified LD_LIBRARY_PATH environment variable.
View DetailsCalendar application allows bypass of authentication by setting a certain cookie value to 1.
View DetailsSetting of a language preference in a cookie enables path traversal attack.
View DetailsServer allows client to specify the search path, which can be modified to point to a program that the client has uploaded.
View DetailsCWE Relationships
No relationship information available for this CWE.
Frequently Asked Questions
What is CWE-642: External Control of Critical State Data?+
CWE-642: External Control of Critical State Data is a Common Weakness Enumeration (CWE) entry maintained by MITRE. The product stores security-critical state information about its users, or the product itself, in a location that is accessible to unauthorized actors. If an attacker can modify the state information without detection, then it could be used to perform unauthorized actions or access unexpected resources, since the application programmer does not expect that the state can be changed. State information can be stored in various locations such as a cookie, in a hidden web form field, input parameter or argument, an environment variable, a database record, within a settings file, etc. All of these locations have the potential to be modified by an attacker. When this state information is used to control security or determine resource usage, then it may create a vulnerability. For example, an application may perform authentication, then save the state in an "authenticated=true" cookie. An attacker may simply create this cookie in order to bypass the authentication.
What are the security consequences of External Control of Critical State Data?+
If exploited, CWE-642 (External Control of Critical State Data) it can compromise Access Control, Confidentiality and Availability, leading to outcomes such as Bypass Protection Mechanism, Gain Privileges or Assume Identity, Read Application Data and DoS: Crash, Exit, or Restart.
How do you prevent or mitigate External Control of Critical State Data?+
Recommended mitigations for CWE-642 include: Understand all the potential locations that are accessible to attackers. For example, some programmers assume that cookies and hidden form fields cannot be modified by an attacker, or they may not consider that environment variables can be modified before a privileged program is invoked. Store state information on the server side only. Ensure that the system definitively and unambiguously keeps track of its own state and user state and has rules defined for legitimate state transitions. Do not allow any application user to affect state directly in any way other than through legitimate actions leading to state transitions. Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible.
Which programming languages are affected by External Control of Critical State Data?+
CWE-642 commonly affects Not Language-Specific. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.
What are real-world examples of External Control of Critical State Data?+
MITRE documents real CVEs mapped to CWE-642, including CVE-2005-2428, CVE-2008-0306, CVE-1999-0073, CVE-2007-4432 and CVE-2006-7191. You can look up the full details of each CVE, including CVSS scores and remediation guidance, on our CVE Lookup tool.
What is the difference between a CWE and a CVE?+
A CWE (Common Weakness Enumeration) like CWE-642 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.