This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Testing for Session Management Schema (OTG-SESS-001)"

From OWASP
Jump to: navigation, search
 
(76 intermediate revisions by 17 users not shown)
Line 1: Line 1:
−
{{Template:OWASP Testing Guide v2}}
+
{{Template:OWASP Testing Guide v4}}
 +
 
 +
== Summary ==
 +
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. These mechanisms are known as Session Management and while they are important in order to increase the ease of use and user-friendliness of the application, they can be exploited by a penetration tester to gain access to a user account, without the need to provide correct credentials.
 +
 
 +
 
 +
In this test, the tester wants to check that cookies and other session tokens are created in a secure and unpredictable way. An attacker who is able to predict and forge a weak cookie can easily hijack the sessions of legitimate users.
 +
 
 +
 
 +
Cookies are used to implement session management and are described in detail in RFC 2965. In a nutshell, when a user accesses an application which needs to keep track of the actions and identity of that user across multiple requests, a cookie (or cookies) is generated by the server and sent to the client. The client will then send the cookie back to the server in all following connections until the cookie expires or is destroyed.  The data stored in the cookie can provide to the server a large spectrum of information about who the user is, what actions he has performed so far, what his preferences are,  etc. therefore providing a state to a stateless protocol like HTTP.
 +
 
 +
 
 +
A typical example is provided by an online shopping cart. Throughout the session of a user, the application must keep track of his identity, his profile, the products that he has chosen to buy, the quantity, the individual prices, the discounts, etc. Cookies are an efficient way to store and pass this information back and forth (other methods are URL parameters and hidden fields).
 +
 
 +
 
 +
Due to the importance of the data that they store, cookies are therefore vital in the overall security of the application. Being able to tamper with cookies may result in hijacking the sessions of legitimate users, gaining higher privileges in an active session, and in general influencing the operations of the application in an unauthorized way.
 +
 
 +
In this test the tester has to check whether the cookies issued to clients can resist a wide range of attacks aimed to interfere with the sessions of legitimate users and with the application itself. The overall goal is to be able to forge a cookie that will be considered valid by the application and that will provide some kind of unauthorized access (session hijacking, privilege escalation, ...).
 +
 
 +
 
 +
Usually the main steps of the attack pattern are the following:
 +
* '''cookie collection''': collection of a sufficient number of cookie samples;
 +
* '''cookie reverse engineering''': analysis of the cookie generation algorithm;
 +
* '''cookie manipulation''': forging of a valid cookie in order to perform the attack. This last step might require a large number of attempts, depending on how the cookie is created (cookie brute-force attack).
 +
 
 +
 
 +
Another pattern of attack consists of overflowing a cookie. Strictly speaking, this attack has a different nature, since here testers are not trying to recreate a perfectly valid cookie. Instead, the goal is to overflow a memory area, thereby interfering with the correct behavior of the application and possibly injecting (and remotely executing) malicious code.
 +
 
 +
==How to Test==
 +
 
 +
===Black Box Testing and Examples===
 +
 
 +
All interaction between the client and application should be tested at least against the following criteria:
 +
* Are all Set-Cookie directives tagged as Secure?
 +
* Do any Cookie operations take place over unencrypted transport?
 +
* Can the Cookie be forced over unencrypted transport? 
 +
* If so, how does the application maintain security?
 +
* Are any Cookies persistent?
 +
* What Expires= times are used on persistent cookies, and are they reasonable?
 +
* 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====
 +
 
 +
The first step required to manipulate the cookie is to understand how the application creates and manages cookies. For this task, testers have to try to answer the following questions:
 +
 
 +
* How many cookies are used by the application?
 +
Surf the application. Note when cookies are created. Make a list of received cookies, the page that sets them (with the set-cookie directive), the domain for which they are valid, their value, and their characteristics.
 +
* Which parts of the the application generate and/or modify the cookie?
 +
Surfing the application, find which cookies remain constant and which get modified. What events modify the cookie?
 +
* Which parts of the application require this cookie in order to be accessed and utilized?
 +
Find out which parts of the application need a cookie. Access a page, then try again without the cookie, or with a modified value of it. Try to map which cookies are used where.
  
−
== Brief Summary ==
 
−
<br>
 
−
Before the active testing of the Session Management Schema we have to understand how the logic works. Then we can try to break the Schema.
 
−
<br>
 
  
−
== Description of the Issue ==
+
A spreadsheet mapping each cookie to the corresponding application parts and the related information can be a valuable output of this phase.
−
<br>
 
−
The session management schema should be considered alongside the authentication and authorisation schema, and cover at least the questions below from a non technical point of view:
 
−
* Will the application be accessed from shared systems? e.g. Internet Café <br>
 
−
* Is application security of prime concern to the visiting client/customer? <br>
 
−
* How many concurrent sessions may a user have? <br>
 
−
* How long is the inactive timeout on the application?<br>
 
−
* How long is the active timeout? <br>
 
−
* Are sessions transferable from one source IP to another? <br>
 
−
* Is ‘remember my username’ functionality provided? <br>
 
−
* Is ‘automatic login’ functionality provided? <br>
 
−
Having identified the schema in place, the application and its logic must be examined to confirm proper implementation of the schema.
 
−
This phase of testing is intrinsically linked with general application security testing.  Whilst the first Schema questions (is the schema suitable for the site and does the schema meet the application provider’s requirements?) can be analysed in abstract, the final question (Does the site implement the specified schema?) must be considered alongside other technical testing. <br>
 
  
−
The identified schema should be analysed against best practice within the context of the site during our penetration test.
 
−
Where the defined schema deviates from security best practice, the associated risks should be identified and described within the context of the environment.  Security risks and issues should be detailed and quantified, but ultimately, the application provider must make decisions based on the security and usability of the application.
 
−
For example, if it is determined that the site has been designed without inactive session timeouts the application provider should be advised about risks such as replay attacks, long-term attacks based on stolen or compromised Session IDs and abuse of a shared terminal where the application wasn’t logged out.  They must then consider these against other requirements such as convenience of use for clients and disruption of the application by forced re-authentication.
 
−
<br>
 
−
''' Session Management Implementation'''<br>
 
−
In this Chapter we describe how to analyse a Session Schema and how to test it. Technical security testing of Session Management implementation covers two key areas:
 
−
* Integrity of Session ID creation
 
−
* Secure management of active sessions and Session IDs
 
−
The Session ID should be sufficiently unpredictable and abstracted from any private information, and the Session management should be logically secured to prevent any manipulation or circumvention of application security
 
−
These two key areas are interdependent, but should be considered separately for a number of reasons.
 
−
Firstly, the choice of underlying technology to provide the sessions is bewildering and can already include a large number of OTS products and an almost unlimited number of bespoke or proprietary implementations.  Whilst the same technical analysis must be performed on each, established vendor solutions may require a slightly different testing approach and existing security research may exist on the implementation.
 
−
Secondly, even an unpredictable and abstract Session ID may be rendered completely ineffectual should the Session management be flawed.  Similarly, a strong and secure session management implementation may be undermined by a poor Session ID implementation.
 
−
Furthermore, the analyst should closely examine how (and if) the application uses the available Session management.  It is not uncommon to see Microsoft ISS server ASP Session IDs passed religiously back and forth during interaction with an application, only to discover that these are not used by the application logic at all.  It is therefore not correct to say that because an application is built on a ‘proven secure’ platform its Session Management is automatically secure.
 
  
 +
====Session Analysis====
  
−
== Black Box testing and example ==
+
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>
  
−
''' Session Analysis'''<br>
 
  
−
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 analyses and information leakage.<br>
 
 
* Token Structure & Information Leakage
 
* Token Structure & Information Leakage
 
The first stage is to examine the structure and content of a Session ID provided by the application.  A common mistake is to include specific data in the Token instead of issuing a generic value and referencing real data at the server side.
 
The first stage is to examine the structure and content of a Session ID provided by the application.  A common mistake is to include specific data in the Token instead of issuing a generic value and referencing real data at the server side.
−
If the Session ID is clear-text, the structure and pertinent data may be immediately obvious as in Figure 1.
+
 
 +
 
 +
If the Session ID is clear-text, the structure and pertinent data may be immediately obvious as the following:
 
<pre>
 
<pre>
 
192.168.100.1:owaspuser:password:15:58
 
192.168.100.1:owaspuser:password:15:58
 
</pre>
 
</pre>
−
Figure 1<br>
 
  
−
If part or the entire Token appears to be encoded or hashed, it should be compared to various techniques to check for obvious obfuscation.
+
 
−
For example the string “192.168.100.1:owaspuser:password:15:58” is represented in Hex, Base64 and as an MD5 hash in Figure 2.
+
If part or the entire token appears to be encoded or hashed, it should be compared to various techniques to check for obvious obfuscation. For example the string “192.168.100.1:owaspuser:password:15:58” is represented in Hex, Base64 and as an MD5 hash:
 
<pre>
 
<pre>
 
Hex 3139322E3136382E3130302E313A6F77617370757365723A70617373776F72643A31353A3538
 
Hex 3139322E3136382E3130302E313A6F77617370757365723A70617373776F72643A31353A3538
Line 55: Line 79:
 
MD5 01c2fc4f0a817afd8366689bd29dd40a
 
MD5 01c2fc4f0a817afd8366689bd29dd40a
 
</pre>
 
</pre>
−
Figure 2 <br>
+
 
−
Having identified the type of obfuscation, it may be possible to decode back to the original data.  In most cases, however, this is unlikely.  Even so, enumerating the encoding in place from the format of the message may still be useful.  Furthermore, if both the format and obfuscation technique can be deduced, automated brute force attacks could be devised.
+
 
−
Hybrid Rokens may include information such as IP address or User ID together with an encoded portion, as in Figure 3.
+
Having identified the type of obfuscation, it may be possible to decode back to the original data.  In most cases, however, this is unlikely.  Even so, it may be useful to enumerate the encoding in place from the format of the message.  Furthermore, if both the format and obfuscation technique can be deduced, automated brute-force attacks could be devised.
 +
 
 +
 
 +
Hybrid tokens may include information such as IP address or User ID together with an encoded portion, as the following:
 
<pre>
 
<pre>
 
owaspuser:192.168.100.1: a7656fafe94dae72b1e1487670148412
 
owaspuser:192.168.100.1: a7656fafe94dae72b1e1487670148412
 
</pre>
 
</pre>
−
Figure 3 <br>
+
 
−
Having analysed a single Session Token, the representative sample should be examined.
+
 
−
A simple analysis of the Tokens should immediately reveal any obvious patterns.  For example, a 32 bit Token may include 16 bits of static data and 16 bits of variable data.  This may indicate that the first 16 bits represents a fixed attribute of the user – e.g. the username or IP address.
+
Having analyzed a single session token, the representative sample should be examined. A simple analysis of the tokens should immediately reveal any obvious patterns.  For example, a 32 bit token may include 16 bits of static data and 16 bits of variable data.  This may indicate that the first 16 bits represent a fixed attribute of the user – e.g. the username or IP address. If the second 16 bit chunk is incrementing at a regular rate, it may indicate a sequential or even time-based element to the token generation.  See examples.
−
If the second 16 bit chunk is incrementing at a regular rate, it may indicate a sequential or even time-based element to the Token generation.  See Examples.
+
 
−
If static elements to the Tokens are identified, further samples should be gathered varying one potential input element at a time.  For example, login attempts through a different user account or from a different IP address may yield a variance in the previously static portion of the Session Token.
+
 
 +
If static elements to the Tokens are identified, further samples should be gathered, varying one potential input element at a time.  For example, log in attempts through a different user account or from a different IP address may yield a variance in the previously static portion of the session token.
 +
 
 +
 
 
The following areas should be addressed during the single and multiple Session ID structure testing:
 
The following areas should be addressed during the single and multiple Session ID structure testing:
 
* What parts of the Session ID are static?
 
* What parts of the Session ID are static?
−
* What clear-text proprietary information is stored in the Session ID?
+
* What clear-text confidential information is stored in the Session ID? E.g. usernames/UID, IP addresses
−
e.g. usernames/UID, IP addresses
+
* What easily decoded confidential information is stored?
−
* What easily decoded proprietary information is stored?
 
 
* What information can be deduced from the structure of the Session ID?
 
* What information can be deduced from the structure of the Session ID?
−
* What portions of the Session ID are static for the same login conditions?
+
* What portions of the Session ID are static for the same log in conditions?
−
* What obvious patterns are present in the Session ID as a whole, or individual portions?
+
* What obvious patterns are present in the Session ID as a whole, or individual portions?
 +
 
 +
 
 +
====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 analyses may be performed manually and with bespoke or OTS statistical or cryptanalytic tools to deduce any patterns in the Session ID content. Manual checks should include comparisons of Session IDs issued for the same login conditions – e.g., the same username, password, and IP address. 
 +
 
 +
 
 +
Time is an important factor which must also be controlled.  High numbers of simultaneous connections should be made in order to gather samples in the same time window and keep that variable constant.  Even a quantization of 50ms or less may be too coarse and a sample taken in this way may reveal time-based components that would otherwise be missed.
 +
 
 +
 
 +
Variable elements should be analyzed over time to determine whether they are incremental in nature.  Where they are incremental, patterns relating to absolute or elapsed time should be investigated.  Many systems use time as a seed for their pseudo-random elements. Where the patterns are seemingly random, one-way hashes of time or other environmental variations should be considered as a possibility.  Typically, the result of a cryptographic hash is a decimal or hexadecimal number so should be identifiable.
 +
 
  
−
'''Session ID Predictability & Randomness'''<br>
+
In analyzing Session ID sequences, patterns or cycles, static elements and client dependencies should all be considered as possible contributing elements to the structure and function of the application.
−
Analyses of the variable areas (if any) of the Session ID should be undertaken to establish if there are any recognisable or predictable patterns.
+
* Are the Session IDs provably random in nature? Can the resulting values be reproduced?   
−
These analyses may be performed manually and with bespoke or OTS statistical or cryptanalytic tools in order to deduce any patterns in Session ID content.
 
−
Manual checks should include comparisons of Session IDs issued for the same login conditions – e.g. the same username, password and IP address.  Time is an important factor which must also be controlled.  High numbers of simultaneous connections should be made in order to gather samples in the same time window and keep that variable constant.  Even a quantisation of 50ms or less may be too coarse and a sample taken in this way may reveal time-based components that would otherwise be missed.
 
−
Variable elements should be analysed over time to determine whether they are incremental in nature.  Where they are incremental, patterns relating to absolute or elapsed time should be investigated.  Many systems use time as a seed for their pseudo random elements.
 
−
Where the patterns are seemingly random, one-way hashes of time or other environmental variations should be considered as a possibility.  Typically, the result of a cryptographic hash is a decimal or hexadecimal number so should be identifiable.
 
−
In analysing Session IDs sequences, patterns or cycles, static elements and client dependencies should all be considered as possible contributing elements to the structure and function of the application.
 
−
* Are the Session IDs provably random in nature? e.g. Can the result be reproduced?   
 
 
* Do the same input conditions produce the same ID on a subsequent run?
 
* Do the same input conditions produce the same ID on a subsequent run?
 
* Are the Session IDs provably resistant to statistical or cryptanalysis?
 
* Are the Session IDs provably resistant to statistical or cryptanalysis?
 
* What elements of the Session IDs are time-linked?
 
* What elements of the Session IDs are time-linked?
 
* What portions of the Session IDs are predictable? 
 
* What portions of the Session IDs are predictable? 
−
* Can the next ID be deduced even given full knowledge of the generation algorithm and previous IDs?
+
* Can the next ID be deduced, given full knowledge of the generation algorithm and previous IDs?
 +
 
  
−
'''Brute Force Attacks'''<br>
+
====Cookie reverse engineering====
−
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.
+
Now that the tester has enumerated the cookies and has a general idea of their use, it is time to have a deeper look at cookies that seem interesting. Which cookies is the tester interested in? A cookie, in order to provide a secure method of session management, must combine several characteristics, each of which is aimed at protecting the cookie from a different class of attacks.
−
A long session ID (or rather one with a great deal of variance) and a shorter validity period would make it far harder to succeed in a brute force attack.
+
 
 +
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, they 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.
 +
#Tamper resistance: a cookie must resist malicious attempts of modification. If the tester receives a cookie like  IsAdmin=No, it is trivial to modify it to get administrative rights, unless the application performs a double check (for instance, appending to the cookie an encrypted hash of its value)
 +
#Expiration: a critical cookie must be valid only for an appropriate period of time and must be deleted from the disk or memory afterwards to avoid the risk of being replayed. This does not apply to cookies that store non-critical data that needs to be remembered across sessions (e.g., site look-and-feel).
 +
#“Secure” flag: a cookie whose value is critical for the integrity of the session should have this flag enabled in order to allow its transmission only in an encrypted channel to deter eavesdropping.
 +
 
 +
 
 +
The approach here is to collect a sufficient number of instances of a cookie and start looking for patterns in their value. The exact meaning of “sufficient” can vary from a handful of samples, if the cookie generation method is very easy to break, to several thousands, if the tester needs to proceed with some mathematical analysis (e.g., chi-squares, attractors. See later for more information).
 +
 
 +
 
 +
It is important to pay particular attention to the workflow of the application, as the state of a session can have a heavy impact on collected cookies. A cookie collected before being authenticated can be very different from a cookie obtained after the authentication.
 +
 
 +
 
 +
Another aspect to keep into consideration is time. Always record the exact time when a cookie has been obtained, when there is the possibility that time plays a role in the value of the cookie (the server could use a time stamp as part of the cookie value). The time recorded could be the local time or the server's time stamp included in the HTTP response (or both).
 +
 
 +
 
 +
When analyzing the collected values, the tester should try to figure out all variables that could have influenced the cookie value and try to vary them one at the time. Passing to the server modified versions of the same cookie can be very helpful in understanding how the application reads and processes the cookie.
 +
 
 +
 
 +
Examples of checks to be performed at this stage include:
 +
* What character set is used in the cookie? Has the cookie a numeric value? alphanumeric? hexadecimal? What happens if the tester inserts in a cookie characters that do not belong to the expected charset?
 +
* Is the cookie composed of different sub-parts carrying different pieces of information? How are the different parts separated? With which delimiters? Some parts of the cookie could have a higher variance, others might be constant, others could assume only a limited set of values. Breaking down the cookie to its base components is the first and fundamental step.
 +
 
 +
 
 +
An example of an easy-to-spot structured cookie is the following:
 +
 
 +
<pre>
 +
ID=5a0acfc7ffeb919:CR=1:TM=1120514521:LM=1120514521:S=j3am5KzC4v01ba3q
 +
</pre>
 +
 
 +
 
 +
This example shows 5 different fields, carrying different types of data:
 +
 
 +
<pre>
 +
ID – hexadecimal
 +
CR – small integer
 +
TM and LM – large integer. (And curiously they hold the same value. Worth to see what happens modifying one of them)
 +
S – alphanumeric
 +
</pre>
 +
 
 +
 
 +
Even when no delimiters are used, having enough samples can help. As an example, let's look at the following series:
 +
 
 +
<pre>
 +
0123456789abcdef
 +
</pre>
 +
 
 +
 
 +
====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 duration 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.
 +
 
 +
 
 +
A long Session ID (or rather one with a great deal of variance) and a shorter validity period would make it far harder to succeed in a brute force attack.
 
* How long would a brute-force attack on all possible Session IDs take?
 
* How long would a brute-force attack on all possible Session IDs take?
−
* Is the Session ID space large enough to prevent brute forcing? e.g. is the length of the key sufficient when compared to the valid life-span
+
* Is the Session ID space large enough to prevent brute forcing? For example, is the length of the key sufficient when compared to the valid life-span?
−
* Do delays between connection attempts with different Session IDs mitigate the risk of this attack?
+
* Do delays between connection attempts with different Session IDs mitigate the risk of this attack?
 +
 
 +
 
 +
=== Gray Box testing and example ===
 +
If the tester has access to the session management schema implementation, they can check for the following:
 +
* Random Session Token
 +
The Session ID or Cookie issued to the client should not be easily predictable (don't use linear algorithms based on predictable variables such as the  client IP address). The use of cryptographic algorithms with key length of 256 bits is encouraged (like AES).
 +
* Token length
 +
Session ID will be at least 50 characters length.
 +
* Session Time-out
 +
Session token should have a defined time-out (it depends on the criticality of the application managed data)
 +
* Cookie configuration:
 +
** non-persistent: only RAM memory
 +
** secure (set only on HTTPS channel):  Set Cookie: cookie=data; path=/; domain=.aaa.it; secure
 +
** [[HTTPOnly]] (not readable by a script):  Set Cookie: cookie=data; path=/; domain=.aaa.it; [[HTTPOnly]]
 +
 
 +
 
 +
More information here: [[Testing_for_cookies_attributes  (OWASP-SM-002)|Testing for cookies attributes]]
 +
 
  
  
−
'''Testing for Topic X vulnerabilities:''' <br>
+
==Tools==
−
...<br>
+
* OWASP Zed Attack Proxy Project (ZAP) - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project - features a session token analysis mechanism.
−
'''Result Expected:'''<br>
+
* Burp Sequencer - http://www.portswigger.net/suite/sequencer.html
−
...<br><br>
+
* Foundstone CookieDigger - http://www.mcafee.com/us/downloads/free-tools/cookiedigger.aspx
−
== Gray Box testing and example ==
+
* YEHG's JHijack - https://www.owasp.org/index.php/JHijack
−
'''Testing for Topic X vulnerabilities:'''<br>
+
 
−
...<br>
+
==References==
−
'''Result Expected:'''<br>
 
−
...<br><br>
 
−
== References ==
 
 
'''Whitepapers'''<br>
 
'''Whitepapers'''<br>
−
...<br>
+
* RFC 2965 “HTTP State Management Mechanism”
−
'''Tools'''<br>
+
* RFC 1750 “Randomness Recommendations for Security”
−
...<br>
+
* Michal Zalewski: "Strange Attractors and TCP/IP Sequence Number Analysis" (2001): http://lcamtuf.coredump.cx/oldtcp/tcpseq.html
 +
* Michal Zalewski: "Strange Attractors and TCP/IP Sequence Number Analysis - One Year Later" (2002): http://lcamtuf.coredump.cx/newtcp/
 +
* Correlation Coefficient: http://mathworld.wolfram.com/CorrelationCoefficient.html
 +
* Darrin Barrall: "Automated Cookie Analysis" –  http://www.spidynamics.com/assets/documents/SPIcookies.pdf
 +
* ENT: http://fourmilab.ch/random/
 +
* http://seclists.org/lists/fulldisclosure/2005/Jun/0188.html
 +
* Gunter Ollmann: "Web Based Session Management" - http://www.technicalinfo.net
 +
* Matteo Meucci:"MMS Spoofing" - http://www.owasp.org/images/7/72/MMS_Spoofing.ppt
 +
 
 +
<br>
 +
'''Videos'''<br>
 +
* Session Hijacking in Webgoat Lesson - http://yehg.net/lab/pr0js/training/view/owasp/webgoat/WebGoat_SessionMan_SessionHijackingWithJHijack/
 +
 
 +
 
 +
==Related Security Activities==
 +
 
 +
===Description of Session Management Vulnerabilities===
 +
 
 +
See the OWASP articles on [[:Category:Session Management Vulnerability|Session Management Vulnerabilities]].
 +
 
 +
 
 +
===Description of Session Management Countermeasures===
 +
 
 +
See the OWASP articles on [[:Category:Session Management|Session Management Countermeasures]].
 +
 
 +
 
 +
===How to Avoid Session Management Vulnerabilities===
  
 +
See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on how to [[Session Management|Avoid Session Management]] Vulnerabilities.
  
−
== Black Box testing and example ==
 
−
'''Testing for Topic X vulnerabilities:''' <br>
 
−
...<br>
 
−
'''Result Expected:'''<br>
 
−
...<br><br>
 
−
== Gray Box testing and example ==
 
−
'''Testing for Topic X vulnerabilities:'''<br>
 
−
...<br>
 
−
'''Result Expected:'''<br>
 
−
...<br><br>
 
−
== References ==
 
−
'''Whitepapers'''<br>
 
−
...<br>
 
−
'''Tools'''<br>
 
−
...<br>
 
  
−
{{Category:OWASP Testing Project AoC}}
+
===How to Review Code for Session Management| Vulnerabilities===
−
[[OWASP Testing Guide v2 Table of Contents]]
+
 
−
{{Template:Stub}}
+
See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Codereview-Session-Management|Review Code for Session Management]] Vulnerabilities.

Latest revision as of 14:09, 31 July 2014

This article is part of the new OWASP Testing Guide v4.

Back to the OWASP Testing Guide v4 ToC:
   https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents
Back to the OWASP Testing Guide Project:
   https://www.owasp.org/index.php/OWASP_Testing_Project

Summary

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. These mechanisms are known as Session Management and while they are important in order to increase the ease of use and user-friendliness of the application, they can be exploited by a penetration tester to gain access to a user account, without the need to provide correct credentials.


In this test, the tester wants to check that cookies and other session tokens are created in a secure and unpredictable way. An attacker who is able to predict and forge a weak cookie can easily hijack the sessions of legitimate users.


Cookies are used to implement session management and are described in detail in RFC 2965. In a nutshell, when a user accesses an application which needs to keep track of the actions and identity of that user across multiple requests, a cookie (or cookies) is generated by the server and sent to the client. The client will then send the cookie back to the server in all following connections until the cookie expires or is destroyed. The data stored in the cookie can provide to the server a large spectrum of information about who the user is, what actions he has performed so far, what his preferences are, etc. therefore providing a state to a stateless protocol like HTTP.


A typical example is provided by an online shopping cart. Throughout the session of a user, the application must keep track of his identity, his profile, the products that he has chosen to buy, the quantity, the individual prices, the discounts, etc. Cookies are an efficient way to store and pass this information back and forth (other methods are URL parameters and hidden fields).


Due to the importance of the data that they store, cookies are therefore vital in the overall security of the application. Being able to tamper with cookies may result in hijacking the sessions of legitimate users, gaining higher privileges in an active session, and in general influencing the operations of the application in an unauthorized way.

In this test the tester has to check whether the cookies issued to clients can resist a wide range of attacks aimed to interfere with the sessions of legitimate users and with the application itself. The overall goal is to be able to forge a cookie that will be considered valid by the application and that will provide some kind of unauthorized access (session hijacking, privilege escalation, ...).


Usually the main steps of the attack pattern are the following:

  • cookie collection: collection of a sufficient number of cookie samples;
  • cookie reverse engineering: analysis of the cookie generation algorithm;
  • cookie manipulation: forging of a valid cookie in order to perform the attack. This last step might require a large number of attempts, depending on how the cookie is created (cookie brute-force attack).


Another pattern of attack consists of overflowing a cookie. Strictly speaking, this attack has a different nature, since here testers are not trying to recreate a perfectly valid cookie. Instead, the goal is to overflow a memory area, thereby interfering with the correct behavior of the application and possibly injecting (and remotely executing) malicious code.

How to Test

Black Box Testing and Examples

All interaction between the client and application should be tested at least against the following criteria:

  • Are all Set-Cookie directives tagged as Secure?
  • Do any Cookie operations take place over unencrypted transport?
  • Can the Cookie be forced over unencrypted transport?
  • If so, how does the application maintain security?
  • Are any Cookies persistent?
  • What Expires= times are used on persistent cookies, and are they reasonable?
  • 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

The first step required to manipulate the cookie is to understand how the application creates and manages cookies. For this task, testers have to try to answer the following questions:

  • How many cookies are used by the application?

Surf the application. Note when cookies are created. Make a list of received cookies, the page that sets them (with the set-cookie directive), the domain for which they are valid, their value, and their characteristics.

  • Which parts of the the application generate and/or modify the cookie?

Surfing the application, find which cookies remain constant and which get modified. What events modify the cookie?

  • Which parts of the application require this cookie in order to be accessed and utilized?

Find out which parts of the application need a cookie. Access a page, then try again without the cookie, or with a modified value of it. Try to map which cookies are used where.


A spreadsheet mapping each cookie to the corresponding application parts and the related information can be a valuable output of this phase.


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.


  • Token Structure & Information Leakage

The first stage is to examine the structure and content of a Session ID provided by the application. A common mistake is to include specific data in the Token instead of issuing a generic value and referencing real data at the server side.


If the Session ID is clear-text, the structure and pertinent data may be immediately obvious as the following: 

192.168.100.1:owaspuser:password:15:58


If part or the entire token appears to be encoded or hashed, it should be compared to various techniques to check for obvious obfuscation. For example the string “192.168.100.1:owaspuser:password:15:58” is represented in Hex, Base64 and as an MD5 hash: 

Hex	3139322E3136382E3130302E313A6F77617370757365723A70617373776F72643A31353A3538
Base64	MTkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6cGFzc3dvcmQ6MTU6NTg=
MD5	01c2fc4f0a817afd8366689bd29dd40a


Having identified the type of obfuscation, it may be possible to decode back to the original data. In most cases, however, this is unlikely. Even so, it may be useful to enumerate the encoding in place from the format of the message. Furthermore, if both the format and obfuscation technique can be deduced, automated brute-force attacks could be devised.


Hybrid tokens may include information such as IP address or User ID together with an encoded portion, as the following: 

owaspuser:192.168.100.1: a7656fafe94dae72b1e1487670148412


Having analyzed a single session token, the representative sample should be examined. A simple analysis of the tokens should immediately reveal any obvious patterns. For example, a 32 bit token may include 16 bits of static data and 16 bits of variable data. This may indicate that the first 16 bits represent a fixed attribute of the user – e.g. the username or IP address. If the second 16 bit chunk is incrementing at a regular rate, it may indicate a sequential or even time-based element to the token generation. See examples.


If static elements to the Tokens are identified, further samples should be gathered, varying one potential input element at a time. For example, log in attempts through a different user account or from a different IP address may yield a variance in the previously static portion of the session token.


The following areas should be addressed during the single and multiple Session ID structure testing:

  • What parts of the Session ID are static?
  • What clear-text confidential information is stored in the Session ID? E.g. usernames/UID, IP addresses
  • What easily decoded confidential information is stored?
  • What information can be deduced from the structure of the Session ID?
  • What portions of the Session ID are static for the same log in conditions?
  • What obvious patterns are present in the Session ID as a whole, or individual portions?


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 analyses may be performed manually and with bespoke or OTS statistical or cryptanalytic tools to deduce any patterns in the Session ID content. Manual checks should include comparisons of Session IDs issued for the same login conditions – e.g., the same username, password, and IP address.


Time is an important factor which must also be controlled. High numbers of simultaneous connections should be made in order to gather samples in the same time window and keep that variable constant. Even a quantization of 50ms or less may be too coarse and a sample taken in this way may reveal time-based components that would otherwise be missed.


Variable elements should be analyzed over time to determine whether they are incremental in nature. Where they are incremental, patterns relating to absolute or elapsed time should be investigated. Many systems use time as a seed for their pseudo-random elements. Where the patterns are seemingly random, one-way hashes of time or other environmental variations should be considered as a possibility. Typically, the result of a cryptographic hash is a decimal or hexadecimal number so should be identifiable.


In analyzing Session ID sequences, patterns or cycles, static elements and client dependencies should all be considered as possible contributing elements to the structure and function of the application.

  • Are the Session IDs provably random in nature? Can the resulting values be reproduced?
  • Do the same input conditions produce the same ID on a subsequent run?
  • Are the Session IDs provably resistant to statistical or cryptanalysis?
  • What elements of the Session IDs are time-linked?
  • What portions of the Session IDs are predictable?
  • Can the next ID be deduced, given full knowledge of the generation algorithm and previous IDs?


Cookie reverse engineering

Now that the tester has enumerated the cookies and has a general idea of their use, it is time to have a deeper look at cookies that seem interesting. Which cookies is the tester interested in? A cookie, in order to provide a secure method of session management, must combine several characteristics, each of which is aimed at protecting the cookie from a different class of attacks.

These characteristics are summarized below:

  1. 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, they 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.
  2. Tamper resistance: a cookie must resist malicious attempts of modification. If the tester receives a cookie like IsAdmin=No, it is trivial to modify it to get administrative rights, unless the application performs a double check (for instance, appending to the cookie an encrypted hash of its value)
  3. Expiration: a critical cookie must be valid only for an appropriate period of time and must be deleted from the disk or memory afterwards to avoid the risk of being replayed. This does not apply to cookies that store non-critical data that needs to be remembered across sessions (e.g., site look-and-feel).
  4. “Secure” flag: a cookie whose value is critical for the integrity of the session should have this flag enabled in order to allow its transmission only in an encrypted channel to deter eavesdropping.


The approach here is to collect a sufficient number of instances of a cookie and start looking for patterns in their value. The exact meaning of “sufficient” can vary from a handful of samples, if the cookie generation method is very easy to break, to several thousands, if the tester needs to proceed with some mathematical analysis (e.g., chi-squares, attractors. See later for more information).


It is important to pay particular attention to the workflow of the application, as the state of a session can have a heavy impact on collected cookies. A cookie collected before being authenticated can be very different from a cookie obtained after the authentication.


Another aspect to keep into consideration is time. Always record the exact time when a cookie has been obtained, when there is the possibility that time plays a role in the value of the cookie (the server could use a time stamp as part of the cookie value). The time recorded could be the local time or the server's time stamp included in the HTTP response (or both).


When analyzing the collected values, the tester should try to figure out all variables that could have influenced the cookie value and try to vary them one at the time. Passing to the server modified versions of the same cookie can be very helpful in understanding how the application reads and processes the cookie.


Examples of checks to be performed at this stage include:

  • What character set is used in the cookie? Has the cookie a numeric value? alphanumeric? hexadecimal? What happens if the tester inserts in a cookie characters that do not belong to the expected charset?
  • Is the cookie composed of different sub-parts carrying different pieces of information? How are the different parts separated? With which delimiters? Some parts of the cookie could have a higher variance, others might be constant, others could assume only a limited set of values. Breaking down the cookie to its base components is the first and fundamental step.


An example of an easy-to-spot structured cookie is the following: 

ID=5a0acfc7ffeb919:CR=1:TM=1120514521:LM=1120514521:S=j3am5KzC4v01ba3q


This example shows 5 different fields, carrying different types of data: 

ID – hexadecimal
CR – small integer
TM and LM – large integer. (And curiously they hold the same value. Worth to see what happens modifying one of them)
S – alphanumeric


Even when no delimiters are used, having enough samples can help. As an example, let's look at the following series: 

0123456789abcdef


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


A long Session ID (or rather one with a great deal of variance) and a shorter validity period would make it far harder to succeed in a brute force attack.

  • How long would a brute-force attack on all possible Session IDs take?
  • Is the Session ID space large enough to prevent brute forcing? For example, is the length of the key sufficient when compared to the valid life-span?
  • Do delays between connection attempts with different Session IDs mitigate the risk of this attack?


Gray Box testing and example

If the tester has access to the session management schema implementation, they can check for the following:

  • Random Session Token

The Session ID or Cookie issued to the client should not be easily predictable (don't use linear algorithms based on predictable variables such as the client IP address). The use of cryptographic algorithms with key length of 256 bits is encouraged (like AES).

  • Token length

Session ID will be at least 50 characters length.

  • Session Time-out

Session token should have a defined time-out (it depends on the criticality of the application managed data)

  • Cookie configuration:
    • non-persistent: only RAM memory
    • secure (set only on HTTPS channel): Set Cookie: cookie=data; path=/; domain=.aaa.it; secure
    • HTTPOnly (not readable by a script): Set Cookie: cookie=data; path=/; domain=.aaa.it; HTTPOnly


More information here: Testing for cookies attributes


Tools

References

Whitepapers


Videos


Related Security Activities

Description of Session Management Vulnerabilities

See the OWASP articles on Session Management Vulnerabilities.


Description of Session Management Countermeasures

See the OWASP articles on Session Management Countermeasures.


How to Avoid Session Management Vulnerabilities

See the OWASP Development Guide article on how to Avoid Session Management Vulnerabilities.


How to Review Code for Session Management| Vulnerabilities

See the OWASP Code Review Guide article on how to Review Code for Session Management Vulnerabilities.

Retrieved from "https://wiki.owasp.org/index.php?title=Testing_for_Session_Management_Schema_(OTG-SESS-001)&oldid=179568"