Session Management Cheat Sheet - Revision history

Dominique RIGHETTO: Point to the official site

2019-07-15T14:23:39Z

Point to the official site

Thunder-Son: Migration to GitHub

2019-02-14T14:13:13Z

Migration to GitHub

Show changes

Jmanico at 05:47, 11 September 2017

2017-09-11T05:47:24Z

Dan Wallis at 05:01, 27 July 2017

2017-07-27T05:01:51Z

Simon Waters: s/weak/permissive/ for clarity

2017-07-10T09:27:34Z

s/weak/permissive/ for clarity

Simon Waters: Add link to PHP vote against defaulting to strict session management, to make it clear that whilst "strict" is more common in terms of systems, many many permissive systems exist.

2017-07-10T09:26:25Z

Add link to PHP vote against defaulting to strict session management, to make it clear that whilst "strict" is more common in terms of systems, many many permissive systems exist.

Pawel Krawczyk: /* HttpOnly Attribute */ SameSite Attribute

2017-04-21T14:38:08Z

‎HttpOnly Attribute: SameSite Attribute

Pawel Krawczyk: /* HttpOnly Attribute */

2017-04-21T14:37:12Z

‎HttpOnly Attribute

Pawel Krawczyk: /* Secure Attribute */

2017-04-21T14:34:15Z

‎Secure Attribute

Shruti kulkarni: /* Cookies */

2016-01-08T14:37:03Z

‎Cookies

← Older revision		Revision as of 14:23, 15 July 2019
Line 4:		Line 4:
	The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!		The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!

−	Please visit [https://~~github~~.~~com/OWASP/CheatSheetSeries/blob/master~~/cheatsheets/Session_Management_Cheat_Sheet.md Session Management Cheat Sheet] to see the latest version of the cheat sheet.	+	Please visit [https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html Session Management Cheat Sheet] to see the latest version of the cheat sheet.

@@ Line 361: / Line 361: @@
 Raul Siles (DinoSec) - raul[at]dinosec.com
-== Other Cheatsheets ==
+= Other Cheatsheets =
 {{Cheatsheet_Navigation_Body}}

@@ Line 14: / Line 14: @@
 Web applications can create sessions to keep track of anonymous users after the very first user request. An example would be maintaining the user language preference. Additionally, web applications will make use of sessions once the user has authenticated. This ensures the ability to identify the user on any subsequent requests as well as being able to apply security access controls, authorized access to the user private data, and to increase the usability of the application. Therefore, current web applications can provide session capabilities both pre and post authentication.
-Once an authenticated session has been established, the session ID (or token) is temporarily equivalent to the strongest authentication method used by the application, such as username and password, passphrases, one-time passwords (OTP), client-based digital certificates, smartcards, or biometrics (such as fingerprint or eye retina). See the OWASP Authentication Cheat Sheet: https://www.owasp.org/index.php/Authentication_Cheat_Sheet.
+Once an authenticated session has been established, the session ID (or token) is temporarily equivalent to the strongest authentication method used by the application, such as username and password, passphrases, one-time passwords (OTP), client-based digital certificates, smartcards, or biometrics (such as fingerprint or eye retina). See the OWASP [[Authentication Cheat Sheet]].
 HTTP is a stateless protocol (RFC2616 [5]), where each request and response pair is independent of other web interactions. Therefore, in order to introduce the concept of a session, it is required to implement session management capabilities that link both the authentication and access control (or authorization) modules commonly available in web applications:
@@ Line 100: / Line 100: @@
 * Web applications should make use of “HTTP Strict Transport Security (HSTS)” (previously called STS) to enforce HTTPS connections.
-See the OWASP Transport Layer Protection Cheat Sheet: https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet.
+See the OWASP [[Transport Layer Protection Cheat Sheet]].
 It is important to emphasize that SSL/TLS (HTTPS) does not protect against session ID prediction, brute force, client-side tampering or fixation. Yet, session ID disclosure and capture from the network traffic is one of the most prevalent attack vectors even today.
@@ Line 116: / Line 116: @@
 Forcing the web application to only use HTTPS for its communication (even when port TCP/80, HTTP, is closed in the web application host) does not protect against session ID disclosure if the “Secure” cookie has not been set - the web browser can be deceived to disclose the session ID over an unencrypted HTTP connection. The attacker can intercept and manipulate the victim user traffic and inject an HTTP unencrypted reference to the web application that will force the web browser to submit the session ID in the clear.
-See also: [https://www.owasp.org/index.php/SecureFlag SecureFlag]
+See also: [[SecureFlag]]
 == HttpOnly Attribute  ==
@@ Line 122: / Line 122: @@
 The “HttpOnly” cookie attribute instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access the cookies via the DOM document.cookie object. This session ID protection is mandatory to prevent session ID stealing through XSS attacks.
-See the OWASP XSS Prevention Cheat Sheet: https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet.
+See the OWASP [[XSS (Cross Site Scripting) Prevention Cheat Sheet]].
-See also: [https://www.owasp.org/index.php/HttpOnly HttpOnly]
+See also: [[HttpOnly]]
 == SameSite Attribute ==
 SameSite allows a server define a cookie attribute making it impossible to the browser send this cookie along with cross-site requests. The main goal is mitigate the risk of cross-origin information leakage, and provides some protection against cross-site request forgery attacks.
-See also: [https://www.owasp.org/index.php/SameSite SameSite]
+See also: [[SameSite]]
 == Domain and Path Attributes  ==

@@ Line 172: / Line 172: @@
 The session tokens should be handled by the web server if possible or generated via a cryptographically secure random number generator.
-Although the most common mechanism in use today is the strict one (more secure, [https://wiki.php.net/rfc/session-use-strict-mode PHP defaults to weak]). Developers must ensure that the web application does not use a permissive mechanism under certain circumstances. Web applications should never accept a session ID they have never generated, and in case of receiving one, they should generate and offer the user a new valid session ID. Additionally, this scenario should be detected as a suspicious activity and an alert should be generated.
+Although the most common mechanism in use today is the strict one (more secure, [https://wiki.php.net/rfc/session-use-strict-mode PHP defaults to permissive]). Developers must ensure that the web application does not use a permissive mechanism under certain circumstances. Web applications should never accept a session ID they have never generated, and in case of receiving one, they should generate and offer the user a new valid session ID. Additionally, this scenario should be detected as a suspicious activity and an alert should be generated.
 == Manage Session ID as Any Other User Input  ==

@@ Line 3: / Line 3: @@
 {| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
-| valign="top"  style="border-right: 1px dotted gray;padding-right:25px;" |
+| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 = Introduction  =
@@ Line 14: / Line 14: @@
 Web applications can create sessions to keep track of anonymous users after the very first user request. An example would be maintaining the user language preference. Additionally, web applications will make use of sessions once the user has authenticated. This ensures the ability to identify the user on any subsequent requests as well as being able to apply security access controls, authorized access to the user private data, and to increase the usability of the application. Therefore, current web applications can provide session capabilities both pre and post authentication.
-Once an authenticated session has been established, the session ID (or token) is temporarily equivalent to the strongest authentication method used by the application, such as username and password, passphrases, one-time passwords (OTP), client-based digital certificates, smartcards, or biometrics (such as fingerprint or eye retina). See the OWASP Authentication Cheat Sheet: [https://www.owasp.org/index.php/Authentication_Cheat_Sheet https://www.owasp.org/index.php/Authentication_Cheat_Sheet].
+Once an authenticated session has been established, the session ID (or token) is temporarily equivalent to the strongest authentication method used by the application, such as username and password, passphrases, one-time passwords (OTP), client-based digital certificates, smartcards, or biometrics (such as fingerprint or eye retina). See the OWASP Authentication Cheat Sheet: https://www.owasp.org/index.php/Authentication_Cheat_Sheet.
 HTTP is a stateless protocol (RFC2616 [5]), where each request and response pair is independent of other web interactions. Therefore, in order to introduce the concept of a session, it is required to implement session management capabilities that link both the authentication and access control (or authorization) modules commonly available in web applications:
@@ Line 100: / Line 100: @@
 * Web applications should make use of “HTTP Strict Transport Security (HSTS)” (previously called STS) to enforce HTTPS connections.
-See the OWASP Transport Layer Protection Cheat Sheet: [https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet].
+See the OWASP Transport Layer Protection Cheat Sheet: https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet.
 It is important to emphasize that SSL/TLS (HTTPS) does not protect against session ID prediction, brute force, client-side tampering or fixation. Yet, session ID disclosure and capture from the network traffic is one of the most prevalent attack vectors even today.
@@ Line 122: / Line 122: @@
 The “HttpOnly” cookie attribute instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access the cookies via the DOM document.cookie object. This session ID protection is mandatory to prevent session ID stealing through XSS attacks.
-See the OWASP XSS Prevention Cheat Sheet: [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet].
+See the OWASP XSS Prevention Cheat Sheet: https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet.
 See also: [https://www.owasp.org/index.php/HttpOnly HttpOnly]
@@ Line 172: / Line 172: @@
 The session tokens should be handled by the web server if possible or generated via a cryptographically secure random number generator.
-Although the most common mechanism in use today is the strict one (more secure). Developers must ensure that the web application does not use a permissive mechanism under certain circumstances. Web applications should never accept a session ID they have never generated, and in case of receiving one, they should generate and offer the user a new valid session ID. Additionally, this scenario should be detected as a suspicious activity and an alert should be generated.
+Although the most common mechanism in use today is the strict one (more secure, [https://wiki.php.net/rfc/session-use-strict-mode PHP defaults to weak]). Developers must ensure that the web application does not use a permissive mechanism under certain circumstances. Web applications should never accept a session ID they have never generated, and in case of receiving one, they should generate and offer the user a new valid session ID. Additionally, this scenario should be detected as a suspicious activity and an alert should be generated.
 == Manage Session ID as Any Other User Input  ==

← Older revision		Revision as of 14:38, 21 April 2017
Line 125:		Line 125:

	See also: [https://www.owasp.org/index.php/HttpOnly HttpOnly]		See also: [https://www.owasp.org/index.php/HttpOnly HttpOnly]
		+
		+	== SameSite Attribute ==
		+	SameSite allows a server define a cookie attribute making it impossible to the browser send this cookie along with cross-site requests. The main goal is mitigate the risk of cross-origin information leakage, and provides some protection against cross-site request forgery attacks.
		+
		+	See also: [https://www.owasp.org/index.php/SameSite SameSite]

	== Domain and Path Attributes ==		== Domain and Path Attributes ==

@@ Line 140: / Line 140: @@
 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 until the expiration time. Typically, session management capabilities to track users after authentication make use of non-persistent cookies. This forces 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>
+* Ensure that sensitive information is not comprised, by ensuring that sensitive information is not persistent / encrypting / stored on a need basis for the duration of the need
 = Session ID Life Cycle  =