StandardSeverity: MediumCAPEC-39

CAPEC-39: Manipulating Opaque Client-based Data Tokens

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
Abstraction: StandardA specific methodology or technique used in an attack.

Mechanism of attack: Subvert Access Control

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

MediumIf the client site token is obfuscated.
HighIf the client site token is encrypted.

Consequences

Integrity
Modify Data
ConfidentialityAccess ControlAuthorization
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...
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.

Related weaknesses (CWE)

Related attack patterns

Parent

CAPEC-22Exploiting Trust in ClientMeta

More specific patterns

CAPEC-31Accessing/Intercepting/Modifying HTTP CookiesDetailed

Description

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.

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

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.