Testing for Cookie and Session Token Manipulation - Revision history

KirstenS at 16:39, 7 December 2008

2008-12-07T16:39:41Z

Mmeucci: Replacing page with 'This article was merged with Testing_for_Session_Management_Schema'

2008-08-14T14:22:35Z

Replacing page with 'This article was merged with Testing_for_Session_Management_Schema'

Show changes

Mmeucci at 14:20, 14 August 2008

2008-08-14T14:20:30Z

Mmeucci at 14:19, 14 August 2008

2008-08-14T14:19:14Z

Mmeucci at 14:14, 14 August 2008

2008-08-14T14:14:43Z

Mmeucci at 14:08, 14 August 2008

2008-08-14T14:08:34Z

Enigmagic at 00:18, 7 August 2007

2007-08-07T00:18:49Z

Enigmagic: /* References */

2007-08-07T00:14:06Z

‎References

Show changes

Mmeucci: Cookie and Session Token Manipulation AoC moved to Testing for Cookie and Session Token Manipulation: naming convention

2006-12-30T14:15:28Z

Cookie and Session Token Manipulation AoC moved to Testing for Cookie and Session Token Manipulation: naming convention

Mmeucci at 13:46, 30 December 2006

2006-12-30T13:46:32Z

← Older revision		Revision as of 16:39, 7 December 2008
Line 1:		Line 1:
−	This article was merged with [[Testing_for_Session_Management_Schema]]	+	This article was merged with [[Testing_for_Session_Management_Schema (OWASP-SM-001)]]

@@ Line 82: / Line 82: @@
 * What obvious patterns are present in the Session ID as a whole, or individual portions?
-===Session ID Predictability and Randomness===<br>
+===Session ID Predictability and Randomness===
 Analysis of the variable areas (if any) of the Session ID should be undertaken to establish the existence of any recognizable or predictable patterns.
 These analysis may be performed manually and with bespoke or OTS statistical or cryptanalytic tools in order to deduce any patterns in Session ID content.
@@ Line 135: / Line 136: @@
 </pre>
-===Brute Force Attacks===<br>
+===Brute Force Attacks===
 Brute force attacks inevitably lead on from questions relating to predictability and randomness.
 The variance within the Session IDs must be considered together with application session durations and timeouts.  If the variation within the Session IDs is relatively small, and Session ID validity is long, the likelihood of a successful brute-force attack is much higher.

@@ Line 32: / Line 32: @@
 * What HTTP/1.0 Cache-Control settings are used to protect Cookies?
-'''Cookie collection'''
+===Cookie collection===
 The first step required in order to manipulate the cookie is obviously to understand how the application creates and manages cookies. For this task, we have to try to answer the following questions:
@@ Line 45: / Line 45: @@
 A spreadsheet mapping each cookie to the corresponding application parts and the related information can be a valuable output of this phase.
-''' Session Analysis'''
+===Session Analysis===
 The Session Tokens (Cookie, SessionID or Hidden Field) themselves should be examined to ensure their quality from a security perspective.  They should be tested against criteria such as their randomness, uniqueness, resistance to statistical and cryptographic analysis and information leakage.<br>
@@ Line 82: / Line 82: @@
 * What obvious patterns are present in the Session ID as a whole, or individual portions?
-'''Cookie reverse engineering'''
+===Session ID Predictability and Randomness===<br>
-----
+Analysis of the variable areas (if any) of the Session ID should be undertaken to establish the existence of any recognizable or predictable patterns.
 Now that we have enumerated the cookies and have a general idea of their use, it is time to have a deeper look at cookies that seem interesting. Which cookies are we interested in? A cookie, in order to provide a secure method of session management, must combine several characteristics, each of which is aimed to protect the cookie from a different class of attacks. These characteristics are summarized below:
 #Unpredictability: a cookie must contain some amount of hard-to-guess data. The harder it is to forge a valid cookie, the harder is to break into legitimate user's session. If an attacker can guess the cookie used in an active session of a legitimate user, he/she will be able to fully impersonate that user (session hijacking). In order to make a cookie unpredictable, random values and/or cryptography can be used.
@@ Line 120: / Line 134: @@
 0123456789abcdef
 </pre>
 == Gray Box testing and example ==

@@ Line 2: / Line 2: @@
 == Brief Summary ==
-In this test we want to check that cookies and other session tokens are created in a secure and unpredictable way. An attacker that is able to predict and forge a weak cookie can easily hijack sessions of legitimate users.
+In order to avoid continuous authentication for each page of a website or service, web applications implement various mechanisms to store and validate credentials for a pre-determined timespan.<br>
 <br>
@@ Line 29: / Line 30: @@
 * Are cookies that are expected to be transient configured as such?
 * What HTTP/1.1 Cache-Control settings are used to protect Cookies?
 * What HTTP/1.0 Cache-Control settings are used to protect Cookies?
 '''Cookie collection'''
@@ Line 43: / Line 44: @@
 A spreadsheet mapping each cookie to the corresponding application parts and the related information can be a valuable output of this phase.
 '''Cookie reverse engineering'''
@@ Line 91: / Line 129: @@
 * Session Time-out
 Session token should have a defined time-out (it depends on the criticality of the application managed data)
-* Cookie configuration, as described here: [[Testing_for_cookies_attributes]]
+* Cookie configuration:
 ==References==

@@ Line 1: / Line 1: @@
-[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br>
+{{Template:OWASP Testing Guide v3}}
 == Brief Summary ==
@@ Line 84: / Line 83: @@
 </pre>
-==References==
+== Gray Box testing and example ==
-'''Whitepapers'''<br>
+If you can access to session management schema implementation, you can check for the following:
-* RFC 2965 “HTTP State Management Mechanism”
+* Random Session Token
-* RFC 1750 “Randomness Recommendations for Security”
+The sessionID or Cookie issued to the client should not be easily predictable (don't use linear algorithm based on predictable variables or client IPArddr). The use of cryptographic algorithms with key lenght of 256 bits is encouraged (like AES).
-* “Strange Attractors and TCP/IP Sequence Number Analysis”: http://www.bindview.com/Services/Razor/Papers/2001/tcpseq.cfm
+* Token length
-* Correlation Coefficient: http://mathworld.wolfram.com/CorrelationCoefficient.html
+SessionID will be at least 50 characters length.
-* ENT: http://fourmilab.ch/random/
+* Session Time-out
-* http://seclists.org/lists/fulldisclosure/2005/Jun/0188.html
+Session token should have a defined time-out (it depends on the criticality of the application managed data)
-* Darrin Barrall: "Automated Cookie Analisys" –  http://www.spidynamics.com/assets/documents/SPIcookies.pdf
+* Cookie configuration, as described here: [[Testing_for_cookies_attributes]]
 ==References==
@@ Line 111: / Line 102: @@
 * http://seclists.org/lists/fulldisclosure/2005/Jun/0188.html
 * Darrin Barrall: "Automated Cookie Analisys" –  http://www.spidynamics.com/assets/documents/SPIcookies.pdf
 <br>
 '''Tools'''<br>
 * [[:Category:OWASP WebScarab Project|OWASP's WebScarab]] features a session token analysis mechanism. You can read [[How to test session identifier strength with WebScarab]].
 * Foundstone CookieDigger - http://www.foundstone.com/resources/proddesc/cookiedigger.htm

← Older revision	Revision as of 14:15, 30 December 2006
(No difference)

@@ Line 154: / Line 154: @@
 <center> [[Image:Example_of_Cookie_with_identy_in_clear_text.gif]] </center>
-Figure 1 - Example of Cookie with identity in clear text
+<center>Figure 1 - Example of Cookie with identity in clear text</center>
 Source: A Case Study of a Web Application Vulnerability - Matteo Meucci: http://www.owasp.org/docroot/owasp/misc/OWASP-Italy-MMS-Spoofing.zip
@@ Line 162: / Line 162: @@
 An example of a cookie whose value is easy to guess and who can be used to impersonate other users can be found in OWASP WebGoat, in the “Weak Authentication cookie” lesson. In this example, you start with the knowledge of two username/password couples (corresponding to the users 'webgoat' and 'aspect'). The goal is to reverse engineer the cookie creation logic and break into the account of user 'Alice'.
 Authenticating to the application using these known couples, you can collect the corresponding authentication cookies. In table 1 you can find the associations that bind each username/password couple to the corresponding cookie, together with the login exact time.
+<center>
 {| border=1
   || '''Username''' || '''Password''' || '''Authentication Cookie - Time'''
@@ Line 177: / Line 177: @@
 Table 1: Cookie collections
+</center>
 First of all, we can note that the authentication cookie remains constant for the same user across different logons, showing a first critical vulnerability to replay attacks: if we are able to steal a valid cookie (using for example a XSS vulnerability), we can use it to hijack the session of the corresponding user without knowing his/her credentials.
 Additionally, we note that the “webgoat” and “aspect” cookies have a common part: