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: | ||
| − | *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. | + | *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. | ||
*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. |
| + | |||
**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 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. |
*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. | ||
Revision as of 10:14, 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:
- 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.
- 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.
- 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.
