Home > CAPEC List > CAPEC-39: Manipulating Opaque Client-based Data Tokens (Version 3.9)

CAPEC-39: Manipulating Opaque Client-based Data Tokens

Attack Pattern ID: 39
Abstraction: Standard
View customized information:
Description
In circumstances where an application holds important data client-side in tokens (cookies, URLs, data files, and so forth) that data can be manipulated. If client or server-side application components reinterpret that data as authentication tokens or data (such as store item pricing or wallet information) then even opaquely manipulating that data may bear fruit for an Attacker. In this pattern an attacker undermines the assumption that client side tokens have been adequately protected from tampering through use of encryption or obfuscation.
Likelihood Of Attack

High

Typical Severity

Medium

Relationships
Section HelpThis table shows the other attack patterns and high level categories that are related to this attack pattern. These relationships are defined as ChildOf and ParentOf, and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as CanFollow, PeerOf, and CanAlsoBe are defined to show similar attack patterns that the user may want to explore.
NatureTypeIDName
ChildOfMeta Attack PatternMeta Attack Pattern - A meta level attack pattern in CAPEC is a decidedly abstract characterization of a specific methodology or technique used in an attack. A meta attack pattern is often void of a specific technology or implementation and is meant to provide an understanding of a high level approach. A meta level attack pattern is a generalization of related group of standard level attack patterns. Meta level attack patterns are particularly useful for architecture and design level threat modeling exercises.22Exploiting Trust in Client
ParentOfDetailed Attack PatternDetailed Attack Pattern - A detailed level attack pattern in CAPEC provides a low level of detail, typically leveraging a specific technique and targeting a specific technology, and expresses a complete execution flow. Detailed attack patterns are more specific than meta attack patterns and standard attack patterns and often require a specific protection mechanism to mitigate actual attacks. A detailed level attack pattern often will leverage a number of different standard level attack patterns chained together to accomplish a goal.31Accessing/Intercepting/Modifying HTTP Cookies
Section HelpThis table shows the views that this attack pattern belongs to and top level categories within that view.
Execution Flow
Explore

  1. Enumerate information passed to client side: The attacker identifies the parameters used as part of tokens to take business or security decisions

    Techniques
    Use WebScarab to reveal hidden fields while browsing.
    Use a sniffer to capture packets
    View source of web page to find hidden fields
    Examine URL to see if any opaque tokens are in it
    Disassemble or decompile client-side application
    Use debugging tools such as File Monitor, Registry Monitor, Debuggers, etc.

  2. Determine protection mechanism for opaque token: The attacker determines the protection mechanism used to protect the confidentiality and integrity of these data tokens. They may be obfuscated or a full blown encryption may be used.

    Techniques
    Look for signs of well-known character encodings
    Look for cryptographic signatures
    Look for delimiters or other indicators of structure
Experiment

  1. Modify parameter/token values: Trying each parameter in turn, the attacker modifies the values

    Techniques
    Modify tokens logically
    Modify tokens arithmetically
    Modify tokens bitwise
    Modify structural components of tokens
    Modify order of parameters/tokens

  2. Cycle through values for each parameter.: Depending on the nature of the application, the attacker now cycles through values of each parameter and observes the effects of this modification in the data returned by the server

    Techniques
    Use network-level packet injection tools such as netcat
    Use application-level data modification tools such as Tamper Data, WebScarab, TamperIE, etc.
    Use modified client (modified by reverse engineering)
    Use debugging tools to modify data in client
Prerequisites
An attacker already has some access to the system or can steal the client based data tokens from another user who has access to the system.
For an Attacker to viably execute this attack, some data (later interpreted by the application) must be held client-side in a way that can be manipulated without detection. This means that the data or tokens are not CRCd as part of their value or through a separate meta-data store elsewhere.
Skills Required
[Level: Medium]
If the client site token is obfuscated.
[Level: High]
If the client site token is encrypted.
Resources Required
The Attacker needs no special hardware-based resources in order to conduct this attack. Software plugins, such as Tamper Data for Firefox, may help in manipulating URL- or cookie-based data.
Consequences
Section HelpThis table specifies different individual consequences associated with the attack pattern. The Scope identifies the security property that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in their attack. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a pattern will be used to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Integrity
Modify Data
Confidentiality
Access Control
Authorization
Gain Privileges
Mitigations
One solution to this problem is to protect encrypted data with a CRC of some sort. If knowing who last manipulated the data is important, then using a cryptographic "message authentication code" (or hMAC) is prescribed. However, this guidance is not a panacea. In particular, any value created by (and therefore encrypted by) the client, which itself is a "malicious" value, all the protective cryptography in the world can't make the value 'correct' again. Put simply, if the client has control over the whole process of generating and encoding the value, then simply protecting its integrity doesn't help.
Make sure to protect client side authentication tokens for confidentiality (encryption) and integrity (signed hash)
Make sure that all session tokens use a good source of randomness
Perform validation on the server side to make sure that client side data tokens are consistent with what is expected.
Example Instances
With certain price watching websites, that aggregate products available prices, the user can buy items through whichever vendors has product availability, the best price, or other differentiator. Once a user selects an item, the site must broker the purchase of that item with the vendor. Because vendors sell the same product through different channel partners at different prices, token exchange between price watching sites and selling vendors will often contain pricing information. With some price watching sites, manipulating URL-data (which is encrypted) even opaquely yields different prices charged by the fulfilling vendor. If the manipulated price turns out higher, the Attacker can cancel purchase. If the Attacker succeeded in manipulating the token and creating a lower price, they proceed.
Upon successful authentication user is granted an encrypted authentication cookie by the server and it is stored on the client. One piece of information stored in the authentication cookie reflects the access level of the user (e.g. "u" for user). The authentication cookie is encrypted using the Electronic Code Book (ECB) mode, that naively encrypts each of the plaintext blocks to each of the ciphertext blocks separately. An attacker knows the structure of the cookie and can figure out what bits (encrypted) store the information relating to the access level of the user. An attacker modifies the authentication cookie and effectively substitutes "u" for "a" by flipping some of the corresponding bits of ciphertext (trial and error). Once the correct "flip" is found, when the system is accessed, the attacker is granted administrative privileges in the system. Note that in this case an attacker did not have to figure out the exact encryption algorithm or find the secret key, but merely exploit the weakness inherent in using the ECB encryption mode.
Archangel Weblog 0.90.02 allows remote attackers to bypass authentication by setting the ba_admin cookie to 1. See also: CVE-2006-0944
Content History
Submissions
Submission DateSubmitterOrganization
2014年06月23日
(Version 2.6)
CAPEC Content TeamThe MITRE Corporation
Modifications
Modification DateModifierOrganization
2017年01月09日
(Version 2.9)
CAPEC Content TeamThe MITRE Corporation
Updated Related_Attack_Patterns
2019年04月04日
(Version 3.1)
CAPEC Content TeamThe MITRE Corporation
Updated Related_Attack_Patterns
2020年07月30日
(Version 3.3)
CAPEC Content TeamThe MITRE Corporation
Updated Example_Instances
More information is available — Please select a different filter.
Page Last Updated or Reviewed: July 31, 2018

Use of the Common Attack Pattern Enumeration and Classification (CAPEC), and the associated references from this website are subject to the Terms of Use. Copyright © 2007–2025, The MITRE Corporation. CAPEC and the CAPEC logo are trademarks of The MITRE Corporation.

AltStyle によって変換されたページ (->オリジナル) /