Testing for Session Management Schema (OTG-SESS-001)

OWASP Testing Guide v2 Table of Contents

Brief Summary

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.

Description of the Issue

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é
  
• Is application security of prime concern to the visiting client/customer?
  
• How many concurrent sessions may a user have?
  
• How long is the inactive timeout on the application?
  
• How long is the active timeout?
  
• Are sessions transferable from one source IP to another?
  
• Is ‘remember my username’ functionality provided?
  
• Is ‘automatic login’ functionality provided?
  

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.

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.
Session Management Implementation 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 ID analysis will, however, be considered first.

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 analyses 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 in Figure 1.

192.168.100.1:owaspuser:password:15:58

Figure 1

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.

Hex	3139322E3136382E3130302E313A6F77617370757365723A70617373776F72643A31353A3538
Base64	MTkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6cGFzc3dvcmQ6MTU6NTg=
MD5	01c2fc4f0a817afd8366689bd29dd40a

Figure 2
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.

owaspuser:192.168.100.1: a7656fafe94dae72b1e1487670148412

Figure 3
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. 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. 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 proprietary information is stored in the Session ID?

e.g. usernames/UID, IP addresses

• What easily decoded proprietary 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 login conditions?
• What obvious patterns are present in the Session ID as a whole, or individual portions?

Session ID Predictability & Randomness Analyses of the variable areas (if any) of the Session ID should be undertaken to establish if there are any recognisable or predictable patterns. 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?
• 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 even given full knowledge of the generation algorithm and previous IDs?

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. 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? e.g. 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?

Black Box testing and example

Testing for Topic X vulnerabilities:
...
Result Expected:
...

Gray Box testing and example

Testing for Topic X vulnerabilities:
...
Result Expected:
...

References

Whitepapers
...
Tools
...

Black Box testing and example

Testing for Topic X vulnerabilities:
...
Result Expected:
...

Gray Box testing and example

Testing for Topic X vulnerabilities:
...
Result Expected:
...

References

Whitepapers
...
Tools
...

---

OWASP Testing Guide v2

Here is the OWASP Testing Guide v2 Table of Contents OWASP Testing Guide v2 Table of Contents

This article is a stub. You can help OWASP by expanding it or discussing it on its Talk page.