1. Introduction
Users of web applications are recognized by session IDs. That’s why it’s obvious that session management is an important subject. Session management flaws are related to weaknesses in the following categories:
- Generation of session IDs (think about the session IDs that can be predicted)
- Life cycle of session IDs (think about the session IDs that can be disclosed when sent via HTTP instead of HTTPS)
This article is focused on one issue in the life cycle of session IDs – session regeneration. Session regeneration is about setting a new value of a session ID – it can occur for example after successful log in of the user. Possible consequences and attack scenarios are presented when session IDs are not regenerated.
2. Session IDs, Attacker, Regeneration of Session IDs
When the attacker gets the session ID of the user, the game is over – the attacker can impersonate the user. It’s great from the attacker’s perspective, when session IDs are predictable. For those interested in randomness analysis of session IDs – I described this topic in one of my previous articles (Session Randomness Analysis with Burp Suite Sequencer [1]).
For the purpose of this section of the article, let’s assume that the session IDs are not predictable. Moreover, let’s assume that the application doesn’t set a new Session ID when the user logs in (no session regeneration after successful log in) and discuss two scenarios.
The first scenario: the site works over HTTPS (authentication, data integrity and confidentiality provided). One may say that the session ID is secure, because HTTPS is used. However, the HTTP version of the site may also be available (no security, plaintext communication) and the attacker might be able to read the session ID of the victim. It will happen when the cookie related with the session ID doesn’t have a secure flag set, and the request is sent over HTTP. The attacker just sends a link to the HTTP version of the site to the user, who clicks this link. When the attacker can see the traffic between the user and the server, then he can also learn the session ID of the user.
The second scenario: the attacker has access to the machine of the user for a short period of time (think about the user who doesn’t log out of the machine and goes for a coffee). Then the attacker can come to the machine of the user and read the session ID.
Two exemplary scenarios of learning/stealing session IDs were presented. The question is – what would happen if the session IDs were regenerated in these scenarios? Then the attacker could impersonate the user for the time between the last and the next session ID regeneration. And this is better than impersonating the user for a very long time (the case when there is no session regeneration).
Let’s analyze another example to better understand why session regeneration is important.
3. Internet Cafe and Stealing the Session ID of the User
Let’s assume that the application doesn’t regenerate the session ID when the user logs in. The user comes to an Internet Cafe, logs in to the application, uses the application for some time, and goes home.
If there is no session regeneration after successful log in, then every next user that comes to the Internet Case and uses the same application will use the same session ID as the previous user. This is an opportunity for an attacker, who can read the value of the session ID and later impersonate the other users who will come to Internet Cafe and will be using this application. The attacker can now go home and check periodically if this session is active. When the next user logs in, the session becomes active and the attacker can impersonate this user. Actually, as has already been mentioned, the attacker can impersonate other users who will come later to the Internet Cafe and use this application, because the session ID is not regenerated.
If there was a session regeneration after successful log in, then the aforementioned attack would not be possible – the session ID of the next user would be regenerated and the value of the previous session ID (the one read by the attacker) would not be helpful any longer for the attacker.
4. Session Regeneration to Prevent Session Fixation
Let’s assume again that the session ID is not regenerated after successful log in. A cookie is not the only way of delivering the session ID. It might also be sent with the GET method. When this is the case, the user can receive from the attacker a link to the application with a predefined value for the session ID. Then the user logs in and actually uses the session ID chosen by the attacker. From the attacker’s perspective it’s very nice – the attacker doesn’t have to guess or steal the session ID (the attacker can now easily impersonate the user, because he knows the value of the session ID). This attack is called session fixation (you can read more about this attack in one of my previous articles – Understanding Session Fixation[2]).
As we can see, this attack is possible because there is no session regeneration after successful log in. Again – if there was session regeneration, then the predefined value of the session ID would not be used by the user (the new value of the session ID would be set after successful log in).
5. Summary
Session IDs are used to distinguish the users of web applications. Session management flaws are related to weaknesses in:
- Generation of session IDs
- Life cycle of session IDs
Session regeneration is an issue in the life cycle of Session IDs. This article presented why regeneration of session IDs is an important subject. When session regeneration is implemented, the attacker can impersonate the user for the time between the last and the next session ID regeneration – this is better than impersonating the user for a very long time (the case when there is no session regeneration). The example of the shared machine (Internet Cafe) was presented to show how the attacker can impersonate other users when there is no session regeneration in the application. Finally, it was presented how a session fixation attack can be prevented when session IDs are regenerated after successful log in.
References:
[1] Session Randomness Analysis with Burp Suite Sequencer
http://resources.infosecinstitute.com/session-randomness-analysis-burp-suite-sequencer/ (access date: 24 January 2014)
[2] Understanding Session Fixation
http://resources.infosecinstitute.com/understanding-session-fixation/ (access date: 31 October 2013)
No comments:
Post a Comment