| Attack Pattern ID | Pattern Abstraction: Detailed 31 |
| Typical Severity | High |
| Description | Summary
This attack relies on the use of HTTP Cookies to store credentials, state information and other critical data on client systems.
The first form of this attack involves accessing HTTP Cookies to mine for potentially sensitive data contained therein.
The second form of this attack involves intercepting this data as it is transmitted from client to server. This intercepted information is then used by the attacker to impersonate the remote user/session.
The third form is when the cookie’s content is modified by the attacker before it is sent back to the server. Here the attacker seeks to convince the target server to operate on this falsified information.
Attack Execution Flow Explore Obtain copy of cookie: The attacker first needs to obtain a copy of the cookie. The attacker 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. |
Attack Step Techniques |
|---|
| Description | Environments |
|---|
| Obtain cookie from local filesystem (e.g. C:\Documents and Settings\*\Cookies and C:\Documents and Settings\*\Application Data\Mozilla\Firefox\Profiles\*\cookies.txt in Windows) | env-Web | | Sniff cookie using a network sniffer such as Wireshark | env-Web | | Obtain cookie from local memory or filesystem using a utility such as the Firefox Cookie Manager or AnEC Cookie Editor. | env-Web | | Steal cookie via a cross-site scripting attack. | env-Web | | Guess cookie contents if it contains predictable information. | env-Web |
|
Indicators of Susceptibility
|
|---|
| ID | Type | Description | Environments |
|---|
| c31s1i1 | Positive | Cookies used in web application. | env-Web | | c31s1i2 | Negative | Cookies not used in web application. | env-Web |
|
Outcomes |
|---|
| ID | Type | Description |
|---|
| c31s1o1 | Success | Cookie captured by attacker. | | c31s1o2 | Failure | Cookie cannot be captured by attacker. |
|
Security Control |
|---|
| ID | Type | Description |
|---|
| c31s1sc1 | Preventative | To prevent network sniffing, cookies should be transmitted over HTTPS and not plain HTTP. To enforce this on the client side, the "secure" flag should be set on cookies (javax.servlet.http.Cookie.setSecure() in Java, secure flag in setcookie() function in php, etc.). |
Experiment Obtain sensitive information from cookie: The attacker 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. |
Attack Step Techniques |
|---|
| Description | Environments |
|---|
| If cookie shows any signs of being encoded using a standard scheme such as base64, decode it. | env-Web | | Analyze the cookie's contents to determine whether it contains any sensitive information. | env-Web |
|
Indicators of Susceptibility
|
|---|
| ID | Type | Description | Environments |
|---|
| c31s2i1 | Negative | Cookie only contains a random session ID (e.g. ASPSESSIONID, JSESSIONID, etc.) | env-Web | | c31s2i2 | Positive | Cookie contains sensitive information (e.g. "ACCTNO=0234234", or "DBIP=0xaf112a22" -- database server's IP address). | env-Web | | c31s2i3 | Inconclusive | Cookie's contents cannot be deciphered. | env-Web |
|
Outcomes |
|---|
| ID | Type | Description |
|---|
| c31s2o1 | Success | Cookie contains sensitive information that developer did not intent the end user to see. | | c31s2o2 | Failure | Cookie does not contain any sensitive information. |
|
Security Control |
|---|
| ID | Type | Description |
|---|
| c31s2sc1 | Preventative | Do not store sensitive information in cookies unless they are encrypted such that only the server can decrypt them. |
Modify cookie to subvert security controls.: The attacker may be able to modify or replace cookies to bypass security controls in the application. |
Attack Step Techniques |
|---|
| Description | Environments |
|---|
| Modify logical parts of cookie and send it back to server to observe the effects. | env-Web | | Modify numeric parts of cookie arithmetically and send it back to server to observe the effects. | env-Web | | Modify cookie bitwise and send it back to server to observe the effects. | env-Web | | 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 his points and then replace his cookie with an older one to restore his balance. | env-Web |
|
Outcomes |
|---|
| ID | Type | Description |
|---|
| c31s3o1 | Success | Subversion of security controls on server | | c31s3o2 | Failure | Cookie reset by server |
|
Security Controls |
|---|
| ID | Type | Description |
|---|
| c31s3sc1 | Detective | Web server logs contain many messages indicating that invalid cookies were received from client. | | c31s3sc2 | Preventative | Cookies should not contain any information that the user is not allowed to modify, unless that information is never expected to change. In the latter case, the integrity of the cookie should be protected using a digital signature or a message authentication code. |
|
| Attack Prerequisites |
Target server software must be a HTTP daemon that relies on cookies.
|
| Typical Likelihood of Exploit |
High
|
| Methods of Attack | - Modification of Resources
- API Abuse
- Protocol Manipulation
- Time and State
|
| Examples-Instances | Description
There are two main attack vectors for exploiting poorly protected session variables like cookies. One is the local machine itself which can be exploited directly at the physical level or indirectly through XSS and phising. In addition, the man in the middle attack relies on a network sniffer, proxy, or other intermediary to intercept the subject's credentials and use them to impersonate the digital subject on the host. The issue is that once the credentials are intercepted, impersonation is trivial for the attacker to accomplish if no other protection mechanisms are in place.
|
| Attacker Skill or Knowledge Required |
Low → To overwrite session cookie data, and submit targeted attacks via HTTP
High → Exploiting a remote buffer overflow generated by attack
|
| Resources Required |
Ability to send HTTP request containing cookie to server
|
| Solutions and Mitigations |
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.
|
| Attack Motivation-Consequences | - Information Leakage
- Data Modification
- Privilege Escalation
|
| Context Description |
One of the biggest challenges in distributed systems is communicating state between the client and server. A variety of schemes have been used, the de facto standard in web application is HTTP cookies. Because these cookies tie together a client and a server through a session, they are useful to system designers and attackers. Because cookies contain remote generated content they can also contain attack payloads.
Cookies may contain a variety of data that servers use to enforce security policy, including session ID, cookie issuer, cookie issuance timestamp, session timeout, subject IP address, and MAC, however the HTTP server should not assume that the session cookie variables are invulnerable. They may be overwritten by the client and/or intermediaries. Cookies, like "hidden" HTML form fields, are generally assumed by developers to be invisible from a client standpoint, but in fact they are a target.
From a privacy standpoint, cookies leave a digital audit trail that can violate a digital subject's privacy, cookies may persist personal information on hard drives, in browser cache, log files, proxy servers, and other intermediaries.
“Because HTTP is a stateless protocol, cookies (small files that are stored in a client browser) were invented, mostly to preserve state. Poor design of cookie handling systems leaves both clients and HTTP daemons susceptible to buffer overflow attack." [Hoglund and McGraw 04]
|
| Injection Vector |
HTTP cookie
|
| Payload |
Malicious input delivered through cookie in HTTP Request.
|
| Activation Zone |
Client software, such as a browser and its component libraries, or an intermediary
|
| Payload Activation Impact |
1. Enables attacker to leverage state stored in cookie
2. Enables attacker a vector to attack web server and platform
|
| Related Weaknesses | | CWE-ID | Weakness Name | Weakness Relationship Type |
|---|
| 565 | Use of Cookies in Security Decision | Targeted | | 302 | Authentication Bypass by Assumed-Immutable Data | Targeted | | 113 | Failure to Sanitize CRLF Sequences in HTTP Headers (aka 'HTTP Response Splitting') | Targeted | | 539 | Information Leak Through Persistent Cookies | Targeted | | 20 | Insufficient Input Validation | Targeted | | 315 | Plaintext Storage in a Cookie | Targeted | | 384 | Session Fixation | Targeted | | 472 | External Control of Assumed-Immutable Web Parameter | Secondary |
|
| Purpose | Exploitation |
| CIA Impact | | Confidentiality Impact | Integrity Impact | Availability Impact |
|---|
| High | High | Low |
|
| Technical Context | | Architectural Paradigm | Framework | Platform | Language |
|---|
| Client-Server | All | All | All |
|
| References |
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
|
| Source | | Submission(s) |
|---|
| Submitter | Organization | Date | Comment |
|---|
| G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. | Cigital, Inc | 2007-01-01 | |
| Modification(s) |
|---|
| Modifier | Organization | Date | Comment |
|---|
| Gunnar Peterson | Cigital, Inc | 2007-02-28 | Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software" | | Sean Barnum | Cigital, Inc | 2007-03-09 | Review and revise | | Richard Struse | VOXEM, Inc | 2007-03-26 | Review and feedback leading to changes in Name and Description | | Sean Barnum | Cigital, Inc | 2007-04-13 | Modified pattern content according to review and feedback | | Amit Sethi | Cigital, Inc. | 2007-10-29 | Added extended Attack Execution Flow |
|
