| Attack Pattern ID | Pattern Abstraction: Standard 74 |
| Typical Severity | High |
| Description | Summary
An attacker modifies state information maintained by the target software in user-accessible locations. If successful, the target software will use this tainted state information and execute in an unintended manner.
State management is an important function within an application. User state maintained by the application can include usernames, payment information, browsing history as well as application-specific contents such as items in a shopping cart.
Manipulating user state can be employed by an attacker to elevate privilege, conduct fraudulent transactions or otherwise modify the flow of the application to derive certain benefits.
Attack Execution Flow Attacker determines the nature of state management employed by the application. This includes determining the location (client-side, server-side or both) and possibly the items stored as part of user state The attacker now tries to modify the user state contents (possibly blindly if the contents are encrypted or otherwise obfuscated) and observe the effects of this change on the application. Having determined the information stored in the user state and the possible ways to modify it, the attacker can violate it in order to perform illegitimate actions.
|
| Typical Likelihood of Exploit |
Medium
|
| Methods of Attack | - Analysis
- Modification of Resources
|
| Examples-Instances | Description Upon authenticating a user, an application stores the authentication decision (auth=0/1) in a cookies unencrypted. At every request, this cookie is checked to permit or deny a request.
An attacker can easily violate this reprepsentation of user state and set auth=1 at every request in order to gain illegitimate access and elevated privilege in the appplication.
|
| Attacker Skill or Knowledge Required |
Medium: The attacker needs to have knowledge of state management as employed by the target application, and also the ability to manipulate the state in a meaningful way.
|
| Resources Required |
No special resources are required. An attacker can choose to use a data tampering tool to aid in the attack.
|
| Probing Techniques | Analysis: The attacker observes contents of client-side user state variables, stored in coookies or hidden fields or query strings, and modifies them in order to observe their effect on the application. |
| Solutions and Mitigations |
Do not rely solely on user-controllable locations, such as cookies or URL parameters, to maintain user state
Do not store sensitive information, such as usernames or authentication and authorization information, in user-controllable locations.
At all times sensitive information that is part of the user state must be appropriately protected to ensure confidentiality and integrity at each request
|
| Attack Motivation-Consequences | - Privilege Escalation
- Data Modification
|
| Context Description |
User state is persisted in a variety of ways between requests, some of them platform dependent. These include cookies, hidden fields, session objects, cache objects, query strings and the likes.
Content that goes into user state persistence is, however, entirely application dependent. It is, therefore, a design decision to include a particular piece of information to persist as part of user state.
Application designers often include sensitive information such as usernames or card numbers as part of user state that gets exposed to the user. Authentication decisions and authorized role membership are often found in cookies or query strings.
Any such information that can be altered to make the application behave differently is open to tampering by a malicious user. Violation of user state information can cause the application to grant incorrect, often elevated, privileges or leak sensitive information about other users or behave unpredictably so as to benefit an attacker.
This problem is exacerbated by the lack of strong cryptographic protection around such sensitive information.
|
| Injection Vector | User-controllable user state variables |
| Payload | Modified or injected user state variables |
| Activation Zone | State management mechanism of the application |
| Payload Activation Impact | Altered user state leading to information leak or elevated privilege |
| Related Weaknesses | | CWE-ID | Weakness Name | Weakness Relationship Type |
|---|
| 372 | Incomplete Internal State Distinction | Secondary | | 371 | State Issues | Targeted | | 315 | Plaintext Storage in a Cookie | Targeted | | 353 | Failure to Add Integrity Check Value | Targeted |
|
| Related Vulnerabilities | | Vulnerability-ID | Vulnerability Description |
|---|
| CVE-2005-4448 | FlatNuke 2.5.6 verifies authentication credentials based on an MD5 checksum of the admin name and the hashed password rather than the plaintext password, which allows attackers to gain privileges by obtaining the password hash (possibly via CVE-2005-2813), then calculating the credentials and including them in the secid cookie. |
|
| Relevant Security Requirements | Protect user state that is stored client-side with integrity checks to ensure that a malicious user cannot gain unauthroized access to parts of the application Authenticate every request to ensure that it is coming from a legitimate user and that the request is a valid one in the current context. |
| Related Security Principles | - Reluctance To Trust
- Never Assuming That Your Secrets Are Safe
|
| Related Guidelines | - Treat the Entire Inherited Process Context as Unvalidated Input
- Use Well-Known Cryptography Appropriately and Correctly
|
| Purpose | Exploitation |
| CIA Impact | | Confidentiality Impact | Integrity Impact | Availability Impact |
|---|
| High | High | Medium |
|
| Technical Context | | Architectural Paradigm | Framework | Platform | Language |
|---|
| Client-Server | All | All | All |
|
| Source | | Submission(s) |
|---|
| Submitter | Organization | Date | Comment |
|---|
| Chiradeep B Chhaya | Cigital, Inc | 2007-03-08 | Taken over from Eric Dalci |
| Modification(s) |
|---|
| Modifier | Organization | Date | Comment |
|---|
| Sean Barnum | Cigital, Inc | 2007-03-08 | Review and revise | | Richard Struse | VOXEM, Inc | 2007-03-26 | Review and feedback leading to changes in Name and Description | | Sean Barnum | Cigital, Inc | 2007-04-16 | Modified pattern content according to review and feedback |
|
