CAPEC-39 - Manipulating Opaque Client-based Data Tokens

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.

Severity

Likelihood

Confidentiality

Integrity

Availability

  • Attack Methods 1
  • Modification of Resources
  • Purposes 2
  • Penetration
  • Exploitation
  • Sec Principles 4
  • Reluctance to Trust
  • Never Assuming that your Secrets are Safe
  • Least Privilege
  • Complete Mediation
  • Scopes 2
  • Modify application data
  • Integrity
  • Gain privileges / assume identity
  • Authorization
  • Access_Control
  • Confidentiality

Medium level: If the client site token is obfuscated.

High level: If the client site token is encrypted.

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.

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.

Tamper with the client side data token and observe the effects it has on interaction with the system.

This attack is in and of itself a trial-and-error-based probing technique.

Never Use Unvalidated Input as Part of a Directive to any Internal Component

Step 1 - Enumerate information passed to client side

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

Tecnique ID: 1 - Environment(s) env-Web

Use WebScarab to reveal hidden fields while browsing.

Tecnique ID: 2 - Environment(s) env-ClientServer env-Peer2Peer env-CommProtocol

Use a sniffer to capture packets

Tecnique ID: 3 - Environment(s) env-Web

View source of web page to find hidden fields

Tecnique ID: 4 - Environment(s) env-Web

Examine URL to see if any opaque tokens are in it

Tecnique ID: 5 - Environment(s) env-ClientServer env-Peer2Peer

Disassemble or decompile client-side application

Tecnique ID: 6 - Environment(s) env-ClientServer env-Peer2Peer

Use debugging tools such as File Monitor, Registry Monitor, Debuggers, etc.

Indicator ID: 1 - Environment(s) env-Web

Type: Positive

Opaque hidden form fields in a web page

Indicator ID: 2 - Environment(s) env-Web env-Peer2Peer env-ClientServer env-CommProtocol

Type: Positive

Opaque session tokens/tickets

Indicator ID: 3 - Environment(s) env-ClientServer env-Peer2Peer env-CommProtocol

Type: Positive

Opaque protocol fields

Indicator ID: 4 - Environment(s) env-Web env-Peer2Peer env-ClientServer env-CommProtocol

Type: Positive

Opaque Resource Locator


Outcome ID: 1

Type: Success

At least one opaque client-side token found

Outcome ID: 2

Type: Failure

No opaque client-side tokens found


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

Tecnique ID: 1 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Look for signs of well-known character encodings

Tecnique ID: 2 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Look for cryptographic signatures

Tecnique ID: 3 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Look for delimiters or other indicators of structure

Indicator ID: 1 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Type: Positive

Standard signatures of well-known encodings detected

Indicator ID: 2 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Type: Positive

Token or structural block's length being multiple of well-known block size of a cryptographic algorithm

Indicator ID: 3 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Type: Positive

Clear structural boundaries or delimiters

Indicator ID: 4 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Type: Negative

Failure outcome in previous step


Outcome ID: 1

Type: Success

Protection/encoding scheme identified

Outcome ID: 2

Type: Failure

No information about protection/encoding scheme could not be determined



Step 1 - Modify parameter/token values

Trying each parameter in turn, the attacker modifies the values.

Tecnique ID: 1 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Modify tokens logically

Tecnique ID: 2 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Modify tokens arithmetically

Tecnique ID: 3 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Modify tokens bitwise

Tecnique ID: 4 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Modify structural components of tokens

Tecnique ID: 5 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Modify order of parameters/tokens

Indicator ID: 1 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Type: Positive

Success outcome in first step.

Indicator ID: 2 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Type: Negative

Failure outcome in first step


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

Tecnique ID: 1 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Use network-level packet injection tools such as netcat

Tecnique ID: 2 - Environment(s) env-Web

Use application-level data modification tools such as Tamper Data, WebScarab, TamperIE, etc.

Tecnique ID: 3 - Environment(s) env-ClientServer env-Peer2Peer env-CommProtocol

Use modified client (modified by reverse engineering)

Tecnique ID: 4 - Environment(s) env-ClientServer env-Peer2Peer

Use debugging tools to modify data in client

Indicator ID: 1 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Type: Positive

Success outcome in first step

Indicator ID: 2 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Type: Negative

Failure outcome in first step


Security Control ID: 1

Type: Detective

Unexpected/invalid token/parameter value in application logs on server

Security Control ID: 2

Type: Corrective

Reset session upon receipt of unexpected/invalid token/parameter value


Outcome ID: 1

Type: Success

Subversion of security controls on server

Outcome ID: 2

Type: Failure

Client token reset by server

Outcome ID: 3

Type: Inconclusive

Detailed error message describing problem with token, received from server



Sensitive information stored client side must be integrity checked upon return before use

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.