Test Session Timeout (OTG-SESS-007) - Revision history

Andrew Muller at 12:47, 8 August 2014

2014-08-08T12:47:29Z

Andrew Muller: Andrew Muller moved page Test Session Timeout (OTG-SESS-008) to Test Session Timeout (OTG-SESS-007)

2014-08-08T11:58:03Z

Andrew Muller moved page Test Session Timeout (OTG-SESS-008) to Test Session Timeout (OTG-SESS-007)

Andrew Muller at 14:26, 31 July 2014

2014-07-31T14:26:10Z

Jane O'Connor: Final edit

2014-05-17T17:19:09Z

Final edit

Irene Abezgauz: small additions and changes

2014-04-22T21:48:15Z

small additions and changes

Davide Danelon: Created page with "{{Template:OWASP Testing Guide v4}} == Brief Summary ==
In this phase, we check that the application automatically logs out a user when that user has been idle for a ce..."

2013-12-09T17:32:20Z

Created page with "{{Template:OWASP Testing Guide v4}} == Brief Summary == In this phase, we check that the application automatically logs out a user when that user has been idle for a ce..."

New page

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
 
In this phase, we check that the application automatically logs out a user when that user has been idle for a certain amount of time, ensuring that it is not possible to “reuse” the same session and that no sensitive data remains stored in the browser cache.
 
== Description of the Issue ==
 
All applications should implement an idle or inactivity timeout for sessions. This timeout defines the amount of time a session will remain active in case there is no activity by the user, closing and invalidating the session upon the defined idle period since the last HTTP request received by the web application for a given session ID.
 
The most appropriate timeout should be a right balance between security (shorter timeout) and usability (longer timeout) and heavily depends on the criticality of the data handled by the application. For example, a 60 minute logout time for a public forum can be acceptable, but such a long time would be too much in a home banking application (where a maximum timeout of 15 minutes it's, in general, recommended). In any case, any application that does not enforce a timeout-based logout should be considered not secure, unless such behavior is required by a specific functional requirement.
 
The idle timeout limits the chances that an attacker has to guess and use a valid session ID from another user. However, if the attacker is able to hijack a given session, the idle timeout does not limit the attacker’s actions, as he can generate activity on the session periodically to keep the session active for longer periods of time.
 
Session timeout management and expiration must be enforced server-side. If some data, under the control of the client, are used to enforce the session timeout, for example using the session token or other client parameters to track time references (e.g. number of minutes since login time), an attacker could manipulate these to extend the session duration. So the application has to track the inactivity time on the server side and, after the timeout is expired, automatically invalidate the current user's session and delete every data stored on the client.
 
Both actions must be implemented carefully, in order to avoid introducing weaknesses that could be exploited by an attacker to gain unauthorized access if the user forgot to logout from the application.
 
More specifically, as for the logout function, it is important to ensure that all session tokens (e.g. cookies) are properly destroyed or made unusable, and that proper controls are enforced at the server side to prevent the reuse of session tokens.
 
If such actions are not properly carried out, an attacker could replay these session tokens in order to “resurrect” the session of a legitimate user and impersonate him/her (this attack is usually known as 'cookie replay'). Of course, a mitigating factor is that the attacker needs to be able to access those tokens (which are stored on the victim's PC), but, in a variety of cases, this may not be impossible or particularly difficult.
 
The most common scenario for this kind of attack is a public computer that is used to access some private information (e.g., webmail, online bank account): if the user moves away from the computer, without explicitly logging out, and the session timeout is not implemented on the application, then an attacker could access to the same account even long time after, for instance, by simply pressing the “back” button of the browser.
 

== Black Box testing and example ==
 
The same approach that we have seen in the [[Testing for logout functionality (OWASP-SM-007)]] section can be applied when measuring the timeout logout.
 
So the testing methodology is very similar. First, we have to check whether a timeout exists, for instance, by logging in and then killing some time reading some other Testing Guide chapter, waiting for the timeout logout to be triggered. As in the logout function, after the timeout has passed, all session tokens should be destroyed or be unusable.
 
Then, if the timeout is configured, we need to understand whether the timeout is enforced by the client or by the server (or both). If the session cookie is non-persistent (or, more in general, the session token does not store any data about the time), we can assume that the timeout is enforced by the server. If the session token contains some time related data (e.g., login time, or last access time, or expiration date for a persistent cookie), then it's possible that the client is involved in the timeout enforcing. In this case, we could try to modify the token (if it's not cryptographically protected) and see what happens to our session. For instance, we can set the cookie expiration date far in the future and see whether our session can be prolonged.
 
As a general rule, everything should be checked server-side and it should not be possible, by re-setting the session cookies to previous values, to access the application again.
 

== Gray Box testing and example ==
 
As a general rule, we need to check that:
* The logout function effectively destroys all session token, or at least renders them unusable,
* The server performs proper checks on the session state, disallowing an attacker to replay some previous token,
* A timeout is enforced and it is properly enforced by the server. If the server uses an expiration time that is read from a session token that is sent by the client (but this is not advisable), then the token must be cryptographically protected.
 
Note: the most important thing is for the application to invalidate the session on the server side. Generally this means that the code must invoke the appropriate methods, e.g. HttpSession.invalidate() in Java and Session.abandon() in .NET. Clearing the cookies from the browser is advisable, but is not strictly necessary, since if the session is properly invalidated on the server, having the cookie in the browser will not help an attacker.
 

== References ==
'''OWASP Resources'''
* [[Session Management Cheat Sheet]]

@@ Line 23: / Line 23: @@
 === Black Box testing ===
-The same approach seen in the [[Testing for logout functionality (OTG-SESS-007)]] section can be applied when measuring the timeout log out.
+The same approach seen in the [[Testing for logout functionality (OTG-SESS-006)]] section can be applied when measuring the timeout log out.
 <br>

@@ Line 2: / Line 2: @@
-== Brief Summary ==
+== Summary ==
 In this phase testers check that the application automatically logs out a user when that user has been idle for a certain amount of time, ensuring that it is not possible to “reuse” the same session and that no sensitive data remains stored in the browser cache.
 All applications should implement an idle or inactivity timeout for sessions. This timeout defines the amount of time a session will remain active in case there is no activity by the user, closing and invalidating the session upon the defined idle period since the last HTTP request received by the web application for a given session ID. The most appropriate timeout should be a balance between security (shorter timeout) and usability (longer timeout) and heavily depends on the sensitivity level of the data handled by the application. For example, a 60 minute log out time for a public forum can be acceptable, but such a long time would be too much in a home banking application (where a maximum timeout of 15 minutes is recommended). In any case, any application that does not enforce a timeout-based log out should be considered not secure, unless such behavior is required by a specific functional requirement.
@@ Line 21: / Line 20: @@
 The most common scenario for this kind of attack is a public computer that is used to access some private information (e.g., web mail, online bank account). If the user moves away from the computer without explicitly logging out and the session timeout is not implemented on the application, then an attacker could access to the same account by simply pressing the “back” button of the browser.
-== Black Box testing and example ==
+=== Black Box testing ===
-The same approach seen in the [[Testing for logout functionality (OWASP-SM-007)]] section can be applied when measuring the timeout log out.
+The same approach seen in the [[Testing for logout functionality (OTG-SESS-007)]] section can be applied when measuring the timeout log out.
 <br>
@@ Line 35: / Line 35: @@
 <br>
-== Gray Box Testing ==
+=== Gray Box Testing ===
 <br>
 The tester needs to check that:

@@ Line 3: / Line 3: @@
 == Brief Summary ==
-<br>
+In this phase testers check that the application automatically logs out a user when that user has been idle for a certain amount of time, ensuring that it is not possible to “reuse” the same session and that no sensitive data remains stored in the browser cache.
-In this phase, we check that the application automatically logs out a user when that user has been idle for a certain amount of time, ensuring that it is not possible to “reuse” the same session and that no sensitive data remains stored in the browser cache.
-<br>
 == Description of the Issue ==
-All applications should implement an idle or inactivity timeout for sessions. This timeout defines the amount of time a session will remain active in case there is no activity by the user, closing and invalidating the session upon the defined idle period since the last HTTP request received by the web application for a given session ID.
+All applications should implement an idle or inactivity timeout for sessions. This timeout defines the amount of time a session will remain active in case there is no activity by the user, closing and invalidating the session upon the defined idle period since the last HTTP request received by the web application for a given session ID. The most appropriate timeout should be a balance between security (shorter timeout) and usability (longer timeout) and heavily depends on the sensitivity level of the data handled by the application. For example, a 60 minute log out time for a public forum can be acceptable, but such a long time would be too much in a home banking application (where a maximum timeout of 15 minutes is recommended). In any case, any application that does not enforce a timeout-based log out should be considered not secure, unless such behavior is required by a specific functional requirement.
-The most appropriate timeout should be a right balance between security (shorter timeout) and usability (longer timeout) and heavily depends on the sensitivity level of the data handled by the application. For example, a 60 minute logout time for a public forum can be acceptable, but such a long time would be too much in a home banking application (where a maximum timeout of 15 minutes it's, in general, recommended). In any case, any application that does not enforce a timeout-based logout should be considered not secure, unless such behavior is required by a specific functional requirement. <br>
-The idle timeout limits the chances that an attacker has to guess and use a valid session ID from another user, and under certain circumstances could protect public computers from session reuse. However, if the attacker is able to hijack a given session, the idle timeout does not limit the attacker’s actions, as he can generate activity on the session periodically to keep the session active for longer periods of time. <br>
-Session timeout management and expiration must be enforced server-side. If some data, under the control of the client, are used to enforce the session timeout, for example using cookie values or other client parameters to track time references (e.g. number of minutes since login time), an attacker could manipulate these to extend the session duration. So the application has to track the inactivity time on the server side and, after the timeout is expired, automatically invalidate the current user's session and delete every data stored on the client. <br>
+The idle timeout limits the chances that an attacker has to guess and use a valid session ID from another user, and under certain circumstances could protect public computers from session reuse. However, if the attacker is able to hijack a given session, the idle timeout does not limit the attacker’s actions, as he can generate activity on the session periodically to keep the session active for longer periods of time.
-Both actions must be implemented carefully, in order to avoid introducing weaknesses that could be exploited by an attacker to gain unauthorized access if the user forgot to logout from the application.
-More specifically, as for the logout function, it is important to ensure that all session tokens (e.g. cookies) are properly destroyed or made unusable, and that proper controls are enforced at the server side to prevent the reuse of session tokens.
-If such actions are not properly carried out, an attacker could replay these session tokens in order to “resurrect” the session of a legitimate user and impersonate him/her (this attack is usually known as 'cookie replay'). Of course, a mitigating factor is that the attacker needs to be able to access those tokens (which are stored on the victim's PC), but, in a variety of cases, this may not be impossible or particularly difficult. <br>
+Session timeout management and expiration must be enforced server-side. If some data under the control of the client is used to enforce the session timeout, for example using cookie values or other client parameters to track time references (e.g. number of minutes since log in time), an attacker could manipulate these to extend the session duration. So the application has to track the inactivity time on the server side and, after the timeout is expired, automatically invalidate the current user's session and delete every data stored on the client.
-The most common scenario for this kind of attack is a public computer that is used to access some private information (e.g., webmail, online bank account): if the user moves away from the computer, without explicitly logging out, and the session timeout is not implemented on the application, then an attacker could access to the same account even long time after, for instance, by simply pressing the “back” button of the browser.
 == Black Box testing and example ==
 <br>
-The same approach that we have seen in the [[Testing for logout functionality (OWASP-SM-007)]] section can be applied when measuring the timeout logout.
-<br>
+The testing methodology is very similar. First, testers have to check whether a timeout exists, for instance, by logging in and waiting for the timeout log out to be triggered. As in the log out function, after the timeout has passed, all session tokens should be destroyed or be unusable.
-The testing methodology is very similar. First, we have to check whether a timeout exists, for instance, by logging in and then killing some time reading some other Testing Guide chapter, waiting for the timeout logout to be triggered. As in the logout function, after the timeout has passed, all session tokens should be destroyed or be unusable.
-<br>
-Then, if the timeout is configured, we need to understand whether the timeout is enforced by the client or by the server (or both). If the session cookie is non-persistent (or, more in general, the session cookie does not store any data about the time), we can assume that the timeout is enforced by the server. If the session cookie contains some time related data (e.g., login time, or last access time, or expiration date for a persistent cookie), then it's possible that the client is involved in the timeout enforcing. In this case, we could try to modify the cookie (if it's not cryptographically protected) and see what happens to our session. For instance, we can set the cookie expiration date far in the future and see whether our session can be prolonged.
+Then, if the timeout is configured, testers need to understand whether the timeout is enforced by the client or by the server (or both). If the session cookie is non-persistent (or, more in general, the session cookie does not store any data about the time), testers can assume that the timeout is enforced by the server. If the session cookie contains some time related data (e.g., log in time, or last access time, or expiration date for a persistent cookie), then it's possible that the client is involved in the timeout enforcing. In this case, testers could try to modify the cookie (if it's not cryptographically protected) and see what happens to the session. For instance, testers can set the cookie expiration date far in the future and see whether the session can be prolonged.
-<br>
 As a general rule, everything should be checked server-side and it should not be possible, by re-setting the session cookies to previous values, to access the application again.
 <br>
-== Gray Box testing and example ==
+== Gray Box Testing ==
 <br>
-We need to check that:
+The tester needs to check that:
-* The logout function effectively destroys all session token, or at least renders them unusable,
+* The log out function effectively destroys all session token, or at least renders them unusable,
 * The server performs proper checks on the session state, disallowing an attacker to replay previously destroyed session identifiers
 * A timeout is enforced and it is properly enforced by the server. If the server uses an expiration time that is read from a session token that is sent by the client (but this is not advisable), then the token must be cryptographically protected from tampering.
-<br>
-Note: the most important thing is for the application to invalidate the session on the server side. Generally this means that the code must invoke the appropriate methods, e.g. HttpSession.invalidate() in Java and Session.abandon() in .NET. Clearing the cookies from the browser is advisable, but is not strictly necessary, since if the session is properly invalidated on the server, having the cookie in the browser will not help an attacker.
-<br>
+Note that the most important thing is for the application to invalidate the session on the server side. Generally this means that the code must invoke the appropriate methods, e.g. HttpSession.invalidate() in Java and Session.abandon() in .NET. Clearing the cookies from the browser is advisable, but is not strictly necessary, since if the session is properly invalidated on the server, having the cookie in the browser will not help an attacker.
 == References ==
 '''OWASP Resources'''
 * [[Session Management Cheat Sheet]]

← Older revision	Revision as of 11:58, 8 August 2014
(No difference)