ByteOS Network

CAPEC-39:Manipulating Opaque Client-based Data Tokens

Attack Pattern ID:39

Version:v3.9

Attack Pattern Name:Manipulating Opaque Client-based Data Tokens

Abstraction:Standard

Status:Draft

Likelihood of Attack:High

Typical Severity:Medium

Details Content History Related Weaknesses Reports

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

▼Relationships

Nature	Type	ID	Name
ChildOf	M	22	Exploiting Trust in Client
ParentOf	D	31	Accessing/Intercepting/Modifying HTTP Cookies

Nature: ChildOf

Type: Meta

ID: 22

Name: Exploiting Trust in Client

Nature: ParentOf

Type: Detailed

ID: 31

Name: Accessing/Intercepting/Modifying HTTP Cookies

▼Execution Flow

Explore

Enumerate information passed to client side

The attacker identifies the parameters used as part of tokens to take business or security decisions

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

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.

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

Experiment

Modify parameter/token values

Trying each parameter in turn, the attacker modifies the values

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

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

Technique
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

Medium

If the client site token is obfuscated.

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

Scope	Likelihood	Impact	Note
Integrity	N/A	Modify Data	N/A
ConfidentialityAccess ControlAuthorization	N/A	Gain Privileges	N/A

Scope: Integrity

Likelihood: N/A

Impact: Modify Data

Note: N/A

Scope: Confidentiality, Access Control, Authorization

Likelihood: N/A

Impact: Gain Privileges

Note: N/A

▼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

▼Related Weaknesses

ID	Name
CWE-233	Improper Handling of Parameters
CWE-285	Improper Authorization
CWE-302	Authentication Bypass by Assumed-Immutable Data
CWE-315	Cleartext Storage of Sensitive Information in a Cookie
CWE-353	Missing Support for Integrity Check
CWE-384	Session Fixation
CWE-472	External Control of Assumed-Immutable Web Parameter
CWE-539	Use of Persistent Cookies Containing Sensitive Information
CWE-565	Reliance on Cookies without Validation and Integrity Checking

ID: CWE-233

Name: Improper Handling of Parameters

ID: CWE-285

Name: Improper Authorization

ID: CWE-302

Name: Authentication Bypass by Assumed-Immutable Data

ID: CWE-315

Name: Cleartext Storage of Sensitive Information in a Cookie

ID: CWE-353

Name: Missing Support for Integrity Check

ID: CWE-384

Name: Session Fixation

ID: CWE-472

Name: External Control of Assumed-Immutable Web Parameter

ID: CWE-539

Name: Use of Persistent Cookies Containing Sensitive Information

ID: CWE-565

Name: Reliance on Cookies without Validation and Integrity Checking