| Name |
Manipulating Opaque Client-based Data Tokens |
|
| Likelyhood of attack |
Typical severity |
| High |
Medium |
|
| Summary |
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. |
| 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. |
| Execution Flow |
| Step |
Phase |
Description |
Techniques |
| 1 |
Explore |
[Enumerate information passed to client side] The attacker identifies the parameters used as part of tokens to take business or security decisions |
- 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 |
Explore |
[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. |
- Look for signs of well-known character encodings
- Look for cryptographic signatures
- Look for delimiters or other indicators of structure
|
| 3 |
Experiment |
[Modify parameter/token values] Trying each parameter in turn, the attacker modifies the values |
- Modify tokens logically
- Modify tokens arithmetically
- Modify tokens bitwise
- Modify structural components of tokens
- Modify order of parameters/tokens
|
| 4 |
Experiment |
[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 |
- 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
|
|
| Solutions | 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. |
| Related Weaknesses |
|
CWE ID
|
Description
|
| 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 |
|
| Related CAPECS |
|
CAPEC ID
|
Description
|
| CAPEC-22 |
An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack. |
|