CWE-642: External Control of Critical State Data

Description:
The product stores security-critical state information about its users, or the product itself, in a location that is accessible to unauthorized actors.

Extended 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.

Affected languages: Not Language-Specific
Affected technologies: Web Server
Parent weaknesses: CWE-668

Consequences:
  - Access Control: Bypass Protection Mechanism
  - Confidentiality: Read Application Data
  - Availability: DoS: Crash, Exit, or Restart

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin
  - Fuzzing: 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 inject
  - Manual Dynamic Analysis: 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 m

Mitigations:
  - [Architecture and Design] 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.
  - [Architecture and Design] Store 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
  - [Architecture and Design] 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 legitima
  - [Architecture and Design] Use 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

Demonstrative examples:
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; } }

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();

Real-world examples:
  - CVE-2005-2428: Mail client stores password hashes for unrelated accounts in a hidden form field.
  - CVE-2008-0306: Privileged program trusts user-specified environment variable to modify critical configuration settings.
  - CVE-1999-0073: Telnet daemon allows remote clients to specify critical environment variables for the server, leading to code execution.
  - CVE-2007-4432: Untrusted search path vulnerability through modified LD_LIBRARY_PATH environment variable.
  - CVE-2006-7191: Untrusted search path vulnerability through modified LD_LIBRARY_PATH environment variable.