External Control of Critical State Data
This vulnerability occurs when an application stores security-sensitive state data in locations that unauthorized users can access and modify.
Applications often track critical state information—like authentication status, user permissions, or session details—in client-side locations such as cookies, hidden form fields, URL parameters, environment variables, or configuration files. Attackers can tamper with this data because these storage mechanisms are frequently outside the application's direct control. If the app trusts this manipulated state without validation, it can lead to severe security breaches, such as letting an attacker forge an "authenticated=true" cookie to bypass login. To prevent this, developers must never rely on client-side storage for security-critical decisions without robust server-side verification. Treat all client-provided state data as untrusted input. Implement integrity checks like cryptographic signatures, store sensitive state exclusively on the server using secure sessions, and validate all state transitions on the backend to ensure attackers cannot manipulate application logic or access unauthorized resources.
Impact: Bypass Protection MechanismGain 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.
Impact: Read Application Data
The state variables may contain sensitive information that should not be known by the client.
Impact: DoS: 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.
Strategy: Attack Surface Reduction
Strategy: Libraries or Frameworks
Strategy: Environment Hardening
Code Example:
javaID : DX-65
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 (Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')).Code Example:
javaID : DX-66
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.Code Example:
javaID : DX-67
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.Code Example:
c/* Raise privileges to those needed for accessing DIR. /
cCode Example:
-
The user sets the PATH to reference a directory under the attacker's control, such as "/my/dir/".
-
The attacker creates a malicious program called "ls", and puts that program in /my/dir
-
The user executes the program.
-
When system() is executed, the shell consults the PATH to find the ls program
-
The program finds the attacker's malicious program, "/my/dir/ls". It doesn't find "/bin/ls" because PATH does not contain "/bin/".
-
The program executes the attacker's malicious program with the raised privileges.
-
Code Example:
perlHigh
- Software Fault Patterns