| Name |
Accessing/Intercepting/Modifying HTTP Cookies |
|
| Likelyhood of attack |
Typical severity |
| High |
High |
|
| Summary |
This attack relies on the use of HTTP Cookies to store credentials, state information and other critical data on client systems. There are several different forms of this attack. The first form of this attack involves accessing HTTP Cookies to mine for potentially sensitive data contained therein. The second form involves intercepting this data as it is transmitted from client to server. This intercepted information is then used by the adversary to impersonate the remote user/session. The third form is when the cookie's content is modified by the adversary before it is sent back to the server. Here the adversary seeks to convince the target server to operate on this falsified information. |
| Prerequisites |
Target server software must be a HTTP daemon that relies on cookies. The cookies must contain sensitive information. The adversary must be able to make HTTP requests to the server, and the cookie must be contained in the reply. |
| Execution Flow |
| Step |
Phase |
Description |
Techniques |
| 1 |
Explore |
[Obtain copy of cookie] The adversary first needs to obtain a copy of the cookie. The adversary may be a legitimate end user wanting to escalate privilege, or could be somebody sniffing on a network to get a copy of HTTP cookies. |
- Sniff cookie using a network sniffer such as Wireshark
- Obtain cookie using a utility such as the Firefox Cookie Manager, Chrome DevTools or AnEC Cookie Editor.
- Steal cookie via a cross-site scripting attack.
- Guess cookie contents if it contains predictable information.
|
| 2 |
Experiment |
[Obtain sensitive information from cookie] The adversary may be able to get sensitive information from the cookie. The web application developers may have assumed that cookies are not accessible by end users, and thus, may have put potentially sensitive information in them. |
- If cookie shows any signs of being encoded using a standard scheme such as base64, decode it.
- Analyze the cookie's contents to determine whether it contains any sensitive information.
|
| 3 |
Experiment |
[Modify cookie to subvert security controls.] The adversary may be able to modify or replace cookies to bypass security controls in the application. |
- Modify logical parts of cookie and send it back to server to observe the effects.
- Modify numeric parts of cookie arithmetically and send it back to server to observe the effects.
- Modify cookie bitwise and send it back to server to observe the effects.
- Replace cookie with an older legitimate cookie and send it back to server to observe the effects. This technique would be helpful in cases where the cookie contains a "points balance" for a given user where the points have some value. The user may spend their points and then replace their cookie with an older one to restore their balance.
|
|
| Solutions | Design: Use input validation for cookies Design: Generate and validate MAC for cookies Implementation: Use SSL/TLS to protect cookie in transit Implementation: Ensure the web server implements all relevant security patches, many exploitable buffer overflows are fixed in patches issued for the software. |
| Related Weaknesses |
|
CWE ID
|
Description
|
| CWE-20 |
Improper Input Validation |
| CWE-113 |
Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting') |
| CWE-302 |
Authentication Bypass by Assumed-Immutable Data |
| CWE-311 |
Missing Encryption of Sensitive Data |
| CWE-315 |
Cleartext Storage of Sensitive Information in a Cookie |
| 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 |
| CWE-602 |
Client-Side Enforcement of Server-Side Security |
| CWE-642 |
External Control of Critical State Data |
|
| Related CAPECS |
|
CAPEC ID
|
Description
|
| CAPEC-39 |
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. |
| CAPEC-157 |
In this attack pattern, the adversary intercepts information transmitted between two third parties. The adversary must be able to observe, read, and/or hear the communication traffic, but not necessarily block the communication or change its content. Any transmission medium can theoretically be sniffed if the adversary can examine the contents between the sender and recipient. Sniffing Attacks are similar to Adversary-In-The-Middle attacks (CAPEC-94), but are entirely passive. AiTM attacks are predominantly active and often alter the content of the communications themselves. |
|