Secure Session Management Cheat Sheet - Revision history

Raul Siles: Title name change - This is the old official page

2011-07-25T10:52:31Z

Title name change - This is the old official page

Show changes

Raul Siles at 23:35, 24 July 2011

2011-07-24T23:35:07Z

Jmanico: /* Logging Sessions Life Cycle: Monitoring Creation, Usage, and Destruction of Session IDs */

2011-07-22T23:11:30Z

‎Logging Sessions Life Cycle: Monitoring Creation, Usage, and Destruction of Session IDs

Raul Siles at 10:46, 19 July 2011

2011-07-19T10:46:23Z

Show changes

Raul Siles at 10:26, 19 July 2011

2011-07-19T10:26:31Z

Show changes

Raul Siles at 22:32, 18 July 2011

2011-07-18T22:32:28Z

Show changes

Raul Siles at 22:15, 18 July 2011

2011-07-18T22:15:28Z

Raul Siles at 22:08, 18 July 2011

2011-07-18T22:08:52Z

Raul Siles at 20:32, 18 July 2011

2011-07-18T20:32:01Z

Raul Siles at 20:14, 18 July 2011

2011-07-18T20:14:28Z

← Older revision		Revision as of 23:35, 24 July 2011
Line 129:		Line 129:

	Session management mechanisms based on cookies can make use of two types of cookies, non-persistent (or session) cookies, and persistent cookies. If a cookie presents the “Max-Age” (that has preference over “Expires”) or “Expires” attributes, it will be considered a persistent cookie and will be stored on disk by the web browser based on the expiration time. Tipically, session management capabilities to track users after authentication make use of non-persistent cookies, forcing the session to disappear from the client if the current web browser instance is closed. Therefore, it is highly recommended to use non-persistent cookies for session management purposes, so that the session ID does not remain on the web client cache for long periods of time, from where an attacker can obtain it.		Session management mechanisms based on cookies can make use of two types of cookies, non-persistent (or session) cookies, and persistent cookies. If a cookie presents the “Max-Age” (that has preference over “Expires”) or “Expires” attributes, it will be considered a persistent cookie and will be stored on disk by the web browser based on the expiration time. Tipically, session management capabilities to track users after authentication make use of non-persistent cookies, forcing the session to disappear from the client if the current web browser instance is closed. Therefore, it is highly recommended to use non-persistent cookies for session management purposes, so that the session ID does not remain on the web client cache for long periods of time, from where an attacker can obtain it.
−
−	~~<br>~~
−
−	~~= Implications of Cookies in Other Web-Based Vulnerabilities =~~
−
−	~~== CSRF ==~~
−
−	The usage of cookies as the session ID exchange mechanim makes web applications vulnerable to Cross-Site Request Forgery (CSRF) attacks, as the existence of an automatic session management mechanism (aka “ambient authority”) allows to get a continuous and transparent authorized access to the web application (aka “session ridding”).
−
−	Other session ID exchange mechanisms do not present this behaviour, such as session IDs exchanged through the URL, where the secret URL (containing the session ID) is not automatically send and thus acts as the authorization mechanism (although these mechanisms present other issues, such as information disclosure). See the OWASP CSRF Prevention Cheat Sheet: [https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet].
−
−	~~== Cross-Site Tracing (XST) ==~~
−
−	The usage of cookies as the session ID exchange mechanim makes web applications the target for the exploitation of Cross-Site Tracing (XST) vulnerabilities, where an attacker tries to get access to the cookies from the response of the HTTP TRACE method. The HTTP TRACE method response includes the full client request as the web server received it, including all HTTP headers and therefore, the session ID in the cookie header. It is highly recommended to disable the HTTP TRACE method in the web server.
−
−	Most modern web browsers do not allow neither the usage of the TRACE method through the Javascript XMLHTTPRequest (XHR) object (to avoid effective XST attacks), nor direct access to the cookie headers (“Set-Cookie”) from the XMLHTTPRequest object responses.
−
−	~~== HTTP Response Splitting ==~~
−
−	The usage of cookies as the session ID exchange mechanim makes web applications the target for the exploitation of HTTP response splitting (or CRLF injection) vulnerabilities, where an attacker can inject end of line characters (CR or LF or CRLF) in specific web application input fields to add his own cookie headers, an effective technique for session fixation attacks [4].
−
−	~~== HTTP Cookie META Tags ==~~
−
−	~~An attacker can take advantage of HTTP META tags within URLs to set cookies, an effective technique for session fixation attacks [4]:~~
−	~~<pre>https://www.example.com/<meta%20http−equiv=Set Cookie%20content="SESSIONID=012345;%20path=/;...">~~
−	~~</pre>~~
−	HTTP META tags are processed by web browsers anywhere within an HTML document and it seems this feature cannot be disabled in web browsers (1), therefore web applications should verify and validate that cookies are not set through META tags (via the URL or other input parameters).
−
−	~~(1) Session Fixation (OWASP): http://www.owasp.org/index.php/Session_fixation~~

	<br>		<br>

@@ Line 279: / Line 279: @@
 Web applications should increase their logging capabilities by including information regarding the full life cycle of sessions. In particular, it is recommended to record session related events, such as the creation, renewal, and destruction of session IDs, as well as details about its usage within login and logout operations, privilege level changes within the session, timeout expiration, invalid session activities (when detected), and critical business operations during the session.
-The log details might include a timestamp, source IP address, web target resource requested (and involved in a session operation), HTTP headers (including the User-Agent and Referer), GET and POST parameters, error codes and messages, username (or user ID), plus the session ID (cookies, URL, GET, POST…). If the session ID is included in the logs, it is mandatory to protect the session logs against session ID local or remote disclosure or unauthorized access.
+The log details might include a timestamp, source IP address, web target resource requested (and involved in a session operation), HTTP headers (including the User-Agent and Referer), GET and POST parameters, error codes and messages, username (or user ID), plus the session ID (cookies, URL, GET, POST…). Sensitive data including the session ID should not be included in the logs in order to protect the session logs against session ID local or remote disclosure or unauthorized access. However, some kind of session-specific information must be logged into order to correlate log entries to specific sessions. It is recommended to log a salted-hash of the session ID instead of the session ID itself in order to allow for session-specific log correlation without exposing the session ID.
 The session logs become one of the main web application intrusion detection data sources, and can also be used by intrusion protection systems to automatically terminate sessions and/or disable user accounts when (one or many) attacks are detected. If active protections are implemented, these defensive actions must be logged too.
 == Simultaneous Session Logons  ==

@@ Line 16: / Line 16: @@
 The disclosure, capture, prediction, brute force, or fixation of the session ID will lead to session hijacking (or sidejacking) attacks, where an attacker is able to fully impersonate a victim user in the web application. Attackers can perform two types of session hijacking attacks, targeted or generic. On a targeted attack, the attacker’s goal is to impersonate a specific (or privileged) web application victim user, while in generic attacks, the attacker’s goal is to impersonate (or get access as) any valid or legitimate user in the web application.
 = Session ID Properties =
@@ Line 43: / Line 44: @@
 If a session ID with an entropy of 64 bits is used, it will take an attacker at least 292 years to successfully guess a valid session ID, assuming the attacker can try 10,000 guesses per second with 100,000 valid simultaneous sessions available in the web application [2].
 == Session ID Content (or Value) ==
@@ Line 51: / Line 51: @@
 It is recommended to create cryptographically strong session IDs through the usage of cryptographic hash functions such as SHA1 (160 bits).
 = Session Management Implementation =
@@ Line 61: / Line 62: @@
 == Built-in Session Management Implementations ==
 Web development frameworks, such as J2EE, ASP .NET, PHP, and others, provide their own session management features and associated implementation. It is recommended to use these built-in frameworks versus building a home made one from scratch, as they are used worldwide on multiple web environments and have been tested by the web application security and development communities over time.
@@ Line 69: / Line 69: @@
 == Used vs. Accepted Session ID Exchange Mechanisms ==
 A specific web application can make use of a particular session ID exchange mechanism by default, such as cookies. However, if a user submits a session ID through a different exchange mechanism, such as a URL parameter, the web application might accept it. Effectively, the web application can use both mechanisms, cookies or URL parameters, or even switch from one to the other (automatic URL rewriting) if certain conditions are met (for example, the existence of web clients without cookies support or if cookies are not accepted due to user privacy concerns).
@@ Line 75: / Line 74: @@
 == Transport Layer Security ==
 In order to protect the session ID exchange from active eavesdropping and passive disclosure in the network traffic, it is mandatory to use an encrypted HTTPS (SSL/TLS) connection for the whole web session, not only for the authentication process where the user credentials are exchanged.
@@ Line 89: / Line 87: @@
 It is important to emphasize that SSL/TLS (HTTPS) does not protect against session ID prediction, brute force, client-side tampering or fixation, but session ID disclosure and capture from the network traffic, one of the most prevalent attack vectors still today.

@@ Line 43: / Line 43: @@
 If a session ID with an entropy of 64 bits is used, it will take an attacker at least 292 years to successfully guess a valid session ID, assuming the attacker can try 10,000 guesses per second with 100,000 valid simultaneous sessions available in the web application [2].
 == Session ID Content (or Value) ==
@@ Line 50: / Line 51: @@
 It is recommended to create cryptographically strong session IDs through the usage of cryptographic hash functions such as SHA1 (160 bits).
 == COMING SOON ==

@@ Line 19: / Line 19: @@
 = Session ID Properties =
-== Title 1.1 ==
+In order to keep the authenticated state and track the users progress within the web application, applications provide users with a session identifier (session ID or token) that is assigned at session creation time, and is shared and exchanged by the user and the web application for the duration of the session (it is sent on every HTTP request). The session ID is a “name=value” pair.
 Text

@@ Line 1: / Line 1: @@
 = Introduction =
-COMING SOON...
+'''Web Authentication, Session Management, and Access Control'''
-= Title 1 =
+Web applications can create sessions to keep track of anonymous users since the very first user request, for example, to maintain the user language preference. Additionally, web applications will make use of sessions once the user has authenticated in order to identify the user on any subsequent requests and be able to apply security access controls, grant access to the user private data, and increase the usability of the application. Therefore, current web applications can provide session capabilities both pre and post authentication.
 == Title 1.1 ==