PUBLIC Session Fixation Vulnerability in Web-based Applications Session Fixation Vulnerability in Web-based Applications Version 1.0 – revision 1 Mitja Kolšek [email protected] ACROS Security http://www.acrossecurity.com December 2002 (Revised February 2007 – the Acknowledgments section) Current copy available at http://www.acrossecurity.com/papers/session_fixation.pdf 1. Abstract Many 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 user’s session ID before the user even logs into the target server, thereby eliminating the need to obtain the user’s 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. Introduction Web-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 user’s 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 user’s 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 PUBLIC Session 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 user’s session can use it to directly enter that session – often without arising user’s suspicion. Interestingly, most cross-site scripting [3] proof-of-concept exploits focus on obtaining the session ID stored in browser’s cookie storage. This class of attacks, where the attacker gains access to the user’s 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 don’t 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 mitiga