Session Fixation Vulnerability

  • View
    1.871

  • Download
    2

Embed Size (px)

DESCRIPTION

Session Fixation Vulnerability inWeb-based Applications

Text of Session Fixation Vulnerability

PUBLICSession Fixation Vulnerability in Web-based Applications

Session Fixation Vulnerability in Web-based ApplicationsVersion 1.0 revision 1 Mitja Kolek ACROS Security December 2002 (Revised February 2007 the Acknowledgments section) Current copy available at http://www.acrossecurity.com/papers/session_fixation.pdf mitja.kolsek@acrossecurity.com http://www.acrossecurity.com

1. AbstractMany web-based applications employ some kind of session management to create a user-friendly environment. Sessions are stored on server and associated with respective users by session identifiers (IDs). Naturally, session IDs present an attractive target for attackers, who, by obtaining them, effectively hijack users identities. Knowing that, web servers are employing techniques for protecting session IDs from three classes of attacks: interception, prediction and brute-force attacks. This paper reveals a fourth class of attacks against session IDs: session fixation attacks. In a session fixation attack, the attacker fixes the users session ID before the user even logs into the target server, thereby eliminating the need to obtain the users session ID afterwards. There are many ways for the attacker to perform a session fixation attack, depending on the session ID transport mechanism (URL arguments, hidden form fields, cookies) and the vulnerabilities available in the target system or its immediate environment. The paper provides detailed information about exploiting vulnerable systems as well as recommendations for protecting them against session fixation attacks.

2. IntroductionWeb-based applications frequently use sessions to provide a friendly environment to their users. HTTP [1] is a stateless protocol, which means that it provides no integrated way for a web server to maintain states throughout users subsequent requests. In order to overcome this problem, web servers or sometimes web applications implement various kinds of session management. The basic idea behind web session management is that the server generates a session identifier (ID) at some early point in user interaction, sends this ID to the users browser and makes sure that this same ID will be sent back by the browser along with each subsequent request. Session IDs thereby become identification tokens for users, and servers can

2002 ACROS d.o.o. [ http://www.acrossecurity.com ]

page 1 of 16

PUBLICSession Fixation Vulnerability in Web-based Applications

use them to maintain session data (e.g., variables) and create a session-like experience to the users. There are three widely used methods for maintaining sessions in web environment: URL arguments, hidden form fields and cookies [2]. While each of them has its benefits and shortcomings, cookies have proven to be the most convenient and also the least insecure of the three. From security perspective, most if not all - known attacks against cookie-based session maintenance schemes can also be used against URL- or hidden form fields-based schemes, while the converse is not true. This makes cookies the best choice security-wise. Very often, session IDs are not only identification tokens, but also authenticators. This means that upon login, users are authenticated based on their credentials (e.g., usernames/passwords or digital certificates) and issued session IDs that will effectively serve as temporary static passwords for accessing their sessions. This makes session IDs a very appealing target for attackers. In many cases, an attacker who manages to obtain a valid ID of users session can use it to directly enter that session often without arising users suspicion. Interestingly, most cross-site scripting [3] proof-of-concept exploits focus on obtaining the session ID stored in browsers cookie storage. This class of attacks, where the attacker gains access to the users session by obtaining his session ID, is called session hijacking [4]. Web session security is focused on preventing three types of attacks against session IDs: interception, prediction and brute-force attacks. Encrypted communication effectively protects against interception1. Using cryptographically strong pseudorandom number generators and carefully chosen seeds that dont leak from the server prevents prediction of session IDs. Finally, session IDs are immune to brute-force methods if their effective bit-length is large enough with respect to the number of simultaneous sessions2. Proposals have been made for mitigating the threat of stolen session IDs [6], and some products already implement such ideas (e.g., RSA Securitys ACE/Agents for web servers).

3. Session fixationAs mentioned above, web session security is mainly focused on preventing the attacker from obtaining either intercepting, predicting or brute-forcing - a session ID issued by the web server (also called target server in this paper) to the users browser. This approach, however, ignores one possibility: namely the possibility of the attacker issuing a session ID to the users browser, thereby forcing the browser into using a chosen session. Well call this class of attacks session fixation attacks, because the users session ID has been fixed in advance instead of having been generated randomly at login time.

1 Although forgetting to mark session ID cookies as secure keeps the attacker's foot in the door [7]. 2

David Endler of iDefense wrote a very interesting article [5] on this topic.page 2 of 16

2002 ACROS d.o.o. [ http://www.acrossecurity.com ]

PUBLICSession Fixation Vulnerability in Web-based Applications

In a session fixation attack, the attacker fixes the users session ID before the user even logs into the target server, thereby eliminating the need to obtain the users session ID afterwards. Lets take a look at a simple example of a session fixation attack. Figure 1 shows a web server online.worldbank.dom that hosts a session-aware web banking application. Session IDs are transported from browser to server within a URL argument sessionid. First, the attacker who in this case is also a legitimate user of the system logs in to the server (1) and is issued a session ID 1234 (2). She then sends a hyperlink http://online.worldbank.dom/login.jsp?sessionid=1234 to the user, trying to lure him into clicking on it (3). The user (how convenient for our example) clicks on the link, which opens the servers login page in his browser (4). Note that upon receipt of the request for login.jsp?sessionid=1234, the web application has established that a session already exists for this user and a new one need not be created. Finally, the user provides his credentials to the login script (5) and the server grants him access to his bank account. However, at this point, knowing the session ID, the attacker can also access the users account via account.jsp?sessionid=1234 (6). Since the session has already been fixed before the user logged in, we say that the user logged into the attackers session.

1

attacker 3

6Log in s es GE sio T /a nid =12 cco unt 34 .jsp ?s e ssi oni d=1 234

http://online.worldbank.dom /login.jsp?sessionid=1234

2

4 5 user

GET /login.jsp?sessionid=1234 username & password online.worldbank.dom

Figure 1: Simple session fixation in an URL-based web banking system

The above example is the simplest and the least dangerous - form of a session fixation attack and has many shortcomings (for the attacker), such as: she has to be a

2002 ACROS d.o.o. [ http://www.acrossecurity.com ]

page 3 of 16

PUBLICSession Fixation Vulnerability in Web-based Applications

legitimate user on the target server and she has to trick the user into logging in through the hyperlink she provided. The following chapters will describe various methods for making session fixation more reliable, less detectable and available to outside attackers (those that are not legitimate users on the target server). But first, lets examine the attack process step by step.

4. Attack processGenerally, session fixation attack is a three-step process, as shown in Figure 2: 1. Session setup: First, the attacker either sets up a so-called trap session on the target server and obtains that sessions ID, or selects a usually arbitrary session ID to be used in the attack. In some cases, the established trap session needs to be maintained (kept alive) by repeatedly sending requests referencing it to avoid idle session timeout. 2. Session fixation: Next, the attacker needs to introduce her session ID to the users browser, thereby fixing his session. 3. Session entrance: Finally, the attacker has to wait until the user logs in to the target server using the previously fixed session ID and then enter the users session.

1

Session setup 1a Session maintenance

2 3

Session fixation Session entrance

Figure 2: Three steps in a session fixation attack

Now lets take a look at the three steps in more detail.

STEP 1: Session setupWe can classify session management mechanisms on web servers in two classes: a) Permissive: those that accept arbitrary session IDs, and create a new session with proposed session ID if one doesnt exist yet (e.g., Macromedia JRun server, PHP). b) Strict: those that only accept known session IDs, which have been locally generated at some point in the past (e.g., Microsoft Internet Information Server).

2002 ACROS d.o.o. [ http://www.acrossecurity.com ]

page 4 of 16

PUBLICSession Fixation Vulnerability in Web-based Applications

For a permissive system, the attacker only needs to make up a random trap session ID, remember it and use it for the attack. In a strict system, the attacker will have to actually establish a trap session with the target server, extract the trap session ID, remember it and use it for the atta

View more >