![]() In this case, testers could try to modify the cookie (if it’s not cryptographically protected) and see what happens to the session. 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. 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. Then, if the timeout is configured, testers need to understand whether the timeout is enforced by the client or by the server (or both). As in the log out function, after the timeout has passed, all session tokens should be destroyed or be unusable. First, testers have to check whether a timeout exists, for instance, by logging in and waiting for the timeout log out to be triggered. The same approach seen in the Testing for logout functionality section can be applied when measuring the timeout log out. Validate that a hard session timeout exists.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. 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). 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. 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’). cookies) are properly destroyed or made unusable, and that proper controls are enforced server-side to prevent the reuse of session tokens. More specifically, as for the log out function, it is important to ensure that all session tokens (e.g. So the application has to track the inactivity time server-side and, after the timeout is expired, automatically invalidate the current user’s session and delete every data stored on the client.īoth 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 log out from the application. ![]() number of minutes since log in time), an attacker could manipulate these to extend the session duration. 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. Session timeout management and expiration must be enforced server-side. 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. 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. 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. ![]() 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). 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. 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. 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.Īll applications should implement an idle or inactivity timeout for sessions. ![]() Home > V42 > 4-Web Application Security Testing > 06-Session Management Testing Testing Session Timeout ID ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |