CRV2 SessionHandling - Revision history

Jonathan Marcil: /* Session Management */

2014-11-28T22:15:37Z

‎Session Management

Jonathan Marcil: /* Recommendation: Require cookies. */

2014-11-28T22:13:47Z

‎Recommendation: Require cookies.

Jonathan Marcil: /* Recommendation: Require cookies. */

2014-11-28T18:57:21Z

‎Recommendation: Require cookies.

Larry Conklin at 20:57, 31 May 2014

2014-05-31T20:57:18Z

Larry Conklin at 20:42, 31 May 2014

2014-05-31T20:42:05Z

Larry Conklin at 20:40, 31 May 2014

2014-05-31T20:40:46Z

Carlos Pantelides at 14:27, 21 May 2014

2014-05-21T14:27:46Z

Abbas Naderi: session fixation and elevation covered

2013-10-18T18:08:00Z

session fixation and elevation covered

Abbas Naderi: initial contents for session handling, needs to add checklists for other two types of attacks

2013-10-18T17:52:45Z

initial contents for session handling, needs to add checklists for other two types of attacks

New page

==General Considerations==
# If the system is critical, Session IDs should be cryptographically secure (i.e non determinable)
# In big systems, sessions should not be stored in files (default PHP behavior). They should be stored in memory or in databases, to prevent DOS attacks on new sessions.
# As soon as a confidential or higher session is formed for a user, they should have all their traffic transmitted through SSL. SessionID is almost as important as passwords.
# A policy should be defined and forced on an application, to define the number of sessions a user can have. (One, Many, etc.) If this is left vague, it usually leads to security flaws.
# Sessions '''require''' a general timeout, which happens at a certain time after creation (usually a week), and an idle timeout, which happens after a certain time of the session being idle (usually 30 minutes).
# The idle timeout can be changed depending on the nature of the application (smaller for banking applications, larger for email composing clients)
# The idle timeout doesn't have to be precise. The application can check for it every 2 minutes, and flush all timed-out idle sessions.

==Session Attacks==
Generally three sorts of session attacks are possible:
# Session Hijacking: stealing someone's session-id, and using it to impersonate that user.
# Session Fixation: setting someone's session-id to a predefined value, and impersonating them using that known value
# Session Elevation: when the importance of a session is changed, but its ID is not.

===Session Hijacking===

# Mostly done via XSS attacks, mostly can be prevented by HTTP-Only session cookies (unless Javascript code requires access to them).
# It's generally a good idea for Javascript not to need access to session cookies, as preventing all flavors of XSS is usually the toughest part of hardening a system.
# Session-ids should be placed inside cookies, and not in URLs. URL informations are stored in browser's history, and HTTP Referrers, and can be accessed by attackers.
# Geographical location checking can help detect simple hijacking scenarios. Advanced hijackers use the same IP (or range) of the victim.
# An active session should be warned when it is accessed from another location.
# An active users should be warned when s/he has an active session somewhere else (if the policy allows multiple sessions for a single user).

@@ Line 46: / Line 46: @@
         type="Samples.AspNet.Session.GuidSessionIDManager" />
   </httpModules>
 ==Session Expiration==

← Older revision		Revision as of 22:13, 28 November 2014
Line 35:		Line 35:

	The SessionID value by default is sent in a cookie with each request to the ASP.NET application.		The SessionID value by default is sent in a cookie with each request to the ASP.NET application.
−
−	~~===Java===~~
−
−
−	~~TODO~~
−
−
−	~~===PHP===~~
−
−	In PHP, a session handled by cookies is created when [http://php.net/manual/en/function.session-start.php session_start()] is called. All security related options for session cookies are in PHP's configuration file php.ini and can be also be set with [http://php.net/manual/en/function.session-set-cookie-params.php session_set_cookie_params()].
−
−	~~session.use_cookies = 1~~
−	~~session.use_only_cookies = 1~~
−	~~session.cookie_httponly = 1~~
−	~~session.cookie_secure = 1~~
−
−	~~See http://php.net/manual/en/session.configuration.php for more information.~~

	==Custom Session frameworks==		==Custom Session frameworks==

← Older revision		Revision as of 18:57, 28 November 2014
Line 35:		Line 35:

	The SessionID value by default is sent in a cookie with each request to the ASP.NET application.		The SessionID value by default is sent in a cookie with each request to the ASP.NET application.
		+
		+	===Java===
		+
		+
		+	TODO
		+
		+
		+	===PHP===
		+
		+	In PHP, a session handled by cookies is created when [http://php.net/manual/en/function.session-start.php session_start()] is called. All security related options for session cookies are in PHP's configuration file php.ini and can be also be set with [http://php.net/manual/en/function.session-set-cookie-params.php session_set_cookie_params()].
		+
		+	session.use_cookies = 1
		+	session.use_only_cookies = 1
		+	session.cookie_httponly = 1
		+	session.cookie_secure = 1
		+
		+	See http://php.net/manual/en/session.configuration.php for more information.

	==Custom Session frameworks==		==Custom Session frameworks==

← Older revision		Revision as of 20:57, 31 May 2014
Line 7:		Line 7:
	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.		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.

		+	[[Image:Session-Management-Diagram Cheat-Sheet.png\|center\|Session-Management-Diagram Cheat-Sheet.png]] <br>

	The session ID or token binds the user authentication credentials (in the form of a user session) to the user HTTP traffic and the appropriate access controls enforced by the web application. The complexity of these three components (authentication, session management, and access control) in modern web applications, plus the fact that its implementation and binding resides on the web developer’s hands (as web development framework do not provide strict relationships between these modules), makes the implementation of a secure session management module very challenging.		The session ID or token binds the user authentication credentials (in the form of a user session) to the user HTTP traffic and the appropriate access controls enforced by the web application. The complexity of these three components (authentication, session management, and access control) in modern web applications, plus the fact that its implementation and binding resides on the web developer’s hands (as web development framework do not provide strict relationships between these modules), makes the implementation of a secure session management module very challenging.

@@ Line 74: / Line 74: @@
 # Session Elevation: when the importance of a session is changed, but its ID is not.
-===Session Hijacking===
+==Session Hijacking==
 # Mostly done via XSS attacks, mostly can be prevented by HTTP-Only session cookies (unless Javascript code requires access to them).
 # (charly proposes to eliminate this...) It's generally a good idea for Javascript not to need access to session cookies, as preventing all flavors of XSS is usually the toughest part of hardening a system.
@@ Line 84: / Line 83: @@
 # An active users should be warned when s/he has an active session somewhere else (if the policy allows multiple sessions for a single user).
-===Session Fixation===
+==Session Fixation==
 # If the application sees a new session-id that is not present in the pool, it should be rejected and a new session-id should be advertised. This is the sole method to prevent fixation.
 # All the session-ids should be generated by the application, and then stored in a pool to be checked later for. Application is the sole authority for session generation.
-===Session Elevation===
+==Session Elevation==
 # Whenever a session is elevated (login, logout, certain authorization), it should be rolled.
 # Many applications create sessions for visitors as well (and not just authenticated users). They should definitely roll the session on elevation, because the user expects the application to treat them securely after they login.

@@ Line 1: / Line 1: @@
-==General Considerations==
+=Session Management=
-# If the system is critical, Session IDs should be cryptographically secure (i.e non determinable)
-# In big systems, sessions should not be stored in files (default PHP behavior). They should be stored in memory or in databases, to prevent DOS attacks on new sessions.
+A web session is a sequence of network HTTP request and response transactions associated to the same user. Session management or state is needed by web applications that require the retaining of information or status about each user for the duration of multiple requests. Therefore, sessions provide the ability to establish variables – such as access rights and localization settings – which will apply to each and every interaction a user has with the web application for the duration of the session.
-# As soon as a confidential or higher session is formed for a user, they should have all their traffic transmitted through SSL. SessionID is almost as important as passwords.
-# A policy should be defined and forced on an application, to define the number of sessions a user can have. (One, Many, etc.) If this is left vague, it usually leads to security flaws.
+Code reviewer needs to understand what session techniques the developers used, and how to spot vulnerabilities that may create potential security risks.
-# Sessions '''require''' a general timeout, which happens at a certain time after creation (usually a week), and an idle timeout, which happens after a certain time of the session being idle (usually 30 minutes).
-# The idle timeout can be changed depending on the nature of the application (smaller for banking applications, larger for email composing clients)
+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.
-# The idle timeout doesn't have to be precise. The application can check for it every 2 minutes, and flush all timed-out idle sessions.
-# Sessions should be rolled when they are elevated. Rolling means that the session-id should be changed, and the session information should be transferred to the new id.
-# Sessions need to be cleared out on logout. It is a good idea to dispose of the session-id on logout as well.
+The session ID or token binds the user authentication credentials (in the form of a user session) to the user HTTP traffic and the appropriate access controls enforced by the web application. The complexity of these three components (authentication, session management, and access control) in modern web applications, plus the fact that its implementation and binding resides on the web developer’s hands (as web development framework do not provide strict relationships between these modules), makes the implementation of a secure session management module very challenging.
 ==Session Attacks==
@@ Line 36: / Line 92: @@
 # Many applications create sessions for visitors as well (and not just authenticated users). They should definitely roll the session on elevation, because the user expects the application to treat them securely after they login.
 # When a down-elevation occurs, the session information regarding the higher level should be flushed.

@@ Line 9: / Line 9: @@
 # Sessions should be rolled when they are elevated. Rolling means that the session-id should be changed, and the session information should be transferred to the new id.
 # Sessions need to be cleared out on logout. It is a good idea to dispose of the session-id on logout as well.
 ==Session Attacks==
@@ Line 19: / Line 21: @@
 # Mostly done via XSS attacks, mostly can be prevented by HTTP-Only session cookies (unless Javascript code requires access to them).
-# It's generally a good idea for Javascript not to need access to session cookies, as preventing all flavors of XSS is usually the toughest part of hardening a system.
+# (charly proposes to eliminate this...) It's generally a good idea for Javascript not to need access to session cookies, as preventing all flavors of XSS is usually the toughest part of hardening a system.
 # Session-ids should be placed inside cookies, and not in URLs. URL informations are stored in browser's history, and HTTP Referrers, and can be accessed by attackers.
 # Geographical location checking can help detect simple hijacking scenarios. Advanced hijackers use the same IP (or range) of the victim.
 # An active session should be warned when it is accessed from another location.