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 "Codereview-Session-Management"

From OWASP
Jump to: navigation, search
(How to Avoid Session Management Vulnerabilities)
Line 23: Line 23:
 
==Description==
 
==Description==
  
Session management from a code review perspective should focus on the creation, renewal, and destruction of a user's session throughout the application.
+
Session management from a code review perspective should focus on the creation, renewal, and destruction of a users' session throughout the application.
 
The code review process should ensure the following:
 
The code review process should ensure the following:
  
Line 35: Line 35:
 
**Session ID should be applied to a new user upon successful authentication.  
 
**Session ID should be applied to a new user upon successful authentication.  
 
**Reviewing the code to identify where sessions are created and invalidated is important.
 
**Reviewing the code to identify where sessions are created and invalidated is important.
**Sessions may need to be terminated upon authorization failures. If a logical condition exists which is not possible unless the state transition is circumvented or an obvious attempt to escalate privileges, a session should be terminated.
+
**Sessions may need to be terminated upon authorization failures. If a logical condition exists which is not possible, unless the state transition is circumvented or an obvious attempt to escalate privileges, a session should be terminated.
  
 
'''Session Transport'''
 
'''Session Transport'''
Line 43: Line 43:
  
 
'''Session lifecycle'''
 
'''Session lifecycle'''
*Session Timeout- Sessions should have a defined inactivity timeout and also in some cases a session hard-limit. The code review should examine such session settings. They may be defined in configuration files or in the code itself. Hard limits shall kill a session regardless of session activity.
+
*Session Timeout - Sessions should have a defined inactivity timeout and also in some cases a session hard-limit. The code review should examine such session settings. They may be defined in configuration files or in the code itself. Hard limits shall kill a session regardless of session activity.
 
**The log-out commands must do more that simply kill the browser. Review the code to verify that log-out commands invalidate the session on the server.
 
**The log-out commands must do more that simply kill the browser. Review the code to verify that log-out commands invalidate the session on the server.
  

Revision as of 14:43, 11 October 2008

Introduction

OWASP Code Review Guide Table of Contents

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 Test for Session Management Vulnerabilities

See the OWASP Testing Guide article on how to Test for Session Management Vulnerabilities.

Description

Session management from a code review perspective should focus on the creation, renewal, and destruction of a users' session throughout the application. The code review process should ensure the following:

Session ID:

  • Authenticated users have a robust and cryptographically secure association with their session.
  • The session identifier (Session ID) shoud not be predictable and generation of such should be left to the underlying framework. The development effort to produce a session with sufficient entropy is subject to errors and best left to tried and trusted methods.

Authorization:

  • Applications enforce authorization checks
  • Applications should check if the session is valid prior to servicing any user requests. The user's session object may also hold authorization data.
    • Session ID should be applied to a new user upon successful authentication.
    • Reviewing the code to identify where sessions are created and invalidated is important.
    • Sessions may need to be terminated upon authorization failures. If a logical condition exists which is not possible, unless the state transition is circumvented or an obvious attempt to escalate privileges, a session should be terminated.

Session Transport

  • Applications avoid or prevent common web attacks, such as replay, request forging and man-in-the-middle.

Session identifiers should be passed to the user in a secure manner such as not using HTTP GET with the session ID being placed in the query string. Such data (query string) is logged in web server logs.

    • Cookie transport should be performed over a secure channel. Review the code in relation to cookie manipulation. Verify is the secure flag is set. This prevents the cookie being transported over a non secure channel.

Session lifecycle

  • Session Timeout - Sessions should have a defined inactivity timeout and also in some cases a session hard-limit. The code review should examine such session settings. They may be defined in configuration files or in the code itself. Hard limits shall kill a session regardless of session activity.
    • The log-out commands must do more that simply kill the browser. Review the code to verify that log-out commands invalidate the session on the server.

Related Vulnerabilities