Difference between revisions of "Codereview-Session-Management"

From OWASP
Jump to: navigation, search
Line 4: Line 4:
 
The code review process should ensure the following:
 
The code review process should ensure the following:
  
 +
'''Session ID:'''
 
*Authenticated users have a robust and cryptographically secure association with their session.  
 
*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 underlaying framework. - The development effort to produce a session with sufficient entrophy is subject to errors and best left to tried and trusted methods.
 
*The session identifier (Session ID) shoud not be predictable and generation of such should be left to the underlaying framework. - The development effort to produce a session with sufficient entrophy is subject to errors and best left to tried and trusted methods.
  
 
+
'''Authorization:'''
 
*Applications enforce authorization checks  
 
*Applications enforce authorization checks  
 
*Applications should check if the session is valid prior to servicing any user requests. The users session object may also hold authorisation data.
 
*Applications should check if the session is valid prior to servicing any user requests. The users session object may also hold authorisation data.
Line 15: Line 16:
 
**Sessions may need to be terminated upon authorization failures. If a logical condition exists which is not pssible unless the state transition is circumvented or an obvious attempt to escalate privlidges, a session should be terminated.
 
**Sessions may need to be terminated upon authorization failures. If a logical condition exists which is not pssible unless the state transition is circumvented or an obvious attempt to escalate privlidges, a session should be terminated.
  
 
+
'''Session Transport'''
 
*Applications avoid or prevent common web attacks, such as replay, request forging and man-in-the-middle.
 
*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.
 
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.
 +
 +
'''Session lifecycle'''
 +
*Session Timeout- Sessions should have a defined inactivity timeout and also in some cases a session hardlimit. 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.

Revision as of 05:19, 4 July 2008

Introduction

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 underlaying framework. - The development effort to produce a session with sufficient entrophy 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 users session object may also hold authorisation 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 pssible unless the state transition is circumvented or an obvious attempt to escalate privlidges, 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.

Session lifecycle

  • Session Timeout- Sessions should have a defined inactivity timeout and also in some cases a session hardlimit. 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.