Goal Reached Thanks to every supporter — we hit 100%!

Goal: 1000 CNY · Raised: 1000 CNY

100.0%

CWE-642 (对关键状态数据的外部可控制) — Vulnerability Class 13

13 vulnerabilities classified as CWE-642 (对关键状态数据的外部可控制). AI Chinese analysis included.

CWE-642 represents a critical weakness where security-sensitive state data, such as user privileges or application configuration, is stored in an accessible location vulnerable to unauthorized modification. Attackers typically exploit this flaw by tampering with client-side storage mechanisms, like cookies or local storage, or by intercepting and altering state variables in transit. Since the application assumes this data remains immutable, successful manipulation allows attackers to bypass authentication, escalate privileges, or access restricted resources without detection. To prevent this, developers must ensure that critical state information is never stored on the client side. Instead, all sensitive state should be maintained securely on the server. If client-side storage is necessary for non-critical data, developers should implement robust integrity checks, such as cryptographic signatures, to detect any unauthorized alterations before the application processes the data.

MITRE CWE Description
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.
Common Consequences (3)
Access ControlBypass Protection Mechanism, Gain Privileges or Assume Identity
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.
ConfidentialityRead Application Data
The state variables may contain sensitive information that should not be known by the client.
AvailabilityDoS: Crash, Exit, or Restart
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.
Mitigations (5)
Architecture and DesignUnderstand 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.
Architecture and DesignStore state information and sensitive data 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. If information must be stored on the cli…
Architecture and DesignStore 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.
Architecture and DesignUse a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. With a stateless protocol such as HTTP, use some frameworks can maintain the state for you. Examples include ASP.NET View State and the OWASP ESAPI Session Management feature. Be careful of language features that provide state support, since these …
Architecture and DesignFor any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Examples (2)
In the following example, an authentication flag is read from a browser cookie, thus allowing for external control of user state data.
Cookie[] cookies = request.getCookies(); for (int i =0; i< cookies.length; i++) { Cookie c = cookies[i]; if (c.getName().equals("authenticated") && Boolean.TRUE.equals(c.getValue())) { authenticated = true; } }
Bad · Java
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).
String rName = request.getParameter("reportName"); File rFile = new File("/usr/local/apfr/reports/" + rName); ... rFile.delete();
Bad · Java

Vulnerabilities classified as CWE-642 (对关键状态数据的外部可控制) represent 13 CVEs. The CWE taxonomy describes the weakness; review individual CVEs for product-specific impact.