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
| 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 10: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.
