Re: Session Fixation

[Gary Gwin <websec () cafesoft com>]

Thanks for posting, this is an excellent article.

One cavaet is with respect to binding the session ID to the browser's 
network address. There are some proxy servers that swap IP addresses 
between HTTP requests. In this case, binding to the exact IP address can 
cause a valid session to be orphaned.

Gary

St. Clair, James wrote:
> FYI - for those who have not seen it..
>
> Jim
>
> -----Original Message-----
> From: TISC Insight [mailto:insight () tisc2003 com]
> Sent: Monday, March 24, 2003 4:13 PM
> To: jstclair () vredenburg com
> Subject: TISC Insight, Volume 5, Issue 3
>
>
> TISC Insight, Volume 5, Issue 3
>
> Welcome to Volume 5, Issue 3 (http://www.tisc2003.com/insight.html#v53) 
> of The Internet Security Conference Newsletter, Insight. Insight provides 
> commentaries and educational columns, authored by some of the best minds 
> in the security community.
>
> TISC is about sharing clue. Our newsletter, Insight, is our way of 
> sharing clue. We promise to provide something useful each issue. If we 
> don't, flame me at mailto:dave () corecom com?subject=flame. If you like the 
> issue, let us know!
>
> Enjoy, and be safe,
> Dave
>
> ----------------------------------------------------------------------
>
>                          From The Editor
>
> Organizations that use Internet firewalls commonly block nearly all 
> inbound services. One common exception is Port 80/HTTP, and predictably, 
> most attacks now concentrate on web application vulnerabilities. Session 
> hijacking is a severe form of web application attack. In today's column, 
> Mitja Kolsek describes how a session "fixation" is accomplished, and 
> recommends ways to mitigate this class of attack.
>
> Happy reading...
>
> ----------------------------------------------------------------------
>
>       Session Fixation Vulnerability in Web-based Applications
>                    Mitja Kolsek, ACROS Security
>                    mailto:mitja.kolsek () acros si 
>
>
> Web-based applications frequently use sessions to provide a friendly 
> environment to their users. HTTP 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 use them to maintain session data (e.g., variables) for 
> creating 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. While each of them has its benefits and 
> shortcomings, cookies have proven to be the most convenient and also the 
> least "unsecure" of the three. 
>
> Very often, session IDs are not only identification tokens, but also 
> authenticators. Upon login, users are authenticated based on their 
> credentials (e.g., usernames/passwords or digital certificates) and 
> issued session IDs that 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 a user's session can use it to directly enter that session - often 
> without raising the user's suspicion. Interestingly, most cross-site 
> scripting 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.
>
> Current 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 
> interception. Using cryptographically strong pseudo-random 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 sessions .
>
> Session fixation
>
> Web session security currently focuses on preventing the attacker from 
> intercepting, predicting or brute-forcing a session ID issued by a web 
> server to the user's browser. This approach, however, ignores one very 
> important issue: the possibility of the attacker "issuing" a session ID 
> to the user's browser, thereby forcing the browser into using a chosen 
> session. We'll call this class of attacks "session fixation" attacks, 
> because the user's session ID has been fixed in advance instead of having 
> been generated randomly at login time.
>
> If you could only remember one sentence, it should be this one: 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.
>
> Now let's take a brief look at the steps in a typical session fixation 
> attack. Note that more details are available in our original paper 
> (http://www.acros.si/papers/session_fixation.pdf). Generally, session 
> fixation attack is a three-step process.
>
> STEP 1: Session Setup
>
> The attacker has two options. He may set up what we call a "trap session" 
> on the target server to obtain that session's ID. Alternatively, he may 
> select the (usually arbitrary) session ID to be used in the attack. In 
> some cases, the established trap session must be maintained (kept alive) 
> by repeatedly sending requests referencing it to avoid idle session 
> timeout.
>
> STEP 2: Session fixation
>
> In this step the attacker tries to transfer the trap session ID to the 
> user's browser. Methods for accomplishing this transfer differ depending 
> on the session ID transport mechanism. Let's examine each method.
>
> Session ID in an URL argument
>
> The attacker must trick the user into logging in to the target web server 
> through the hyperlink she provides, e.g., http://online.worldbank.dom/ 
> login.jsp?session=1234. This method, while feasible, is relatively 
> impractical and comes with quite a risk of detection.
>
> Session ID in a hidden form field
>
> The attacker must trick the user into logging in to the target web server 
> through a familiar but bogus login form; in reality, the form is 
> presented from another web server. This method is at least as impractical 
> and detection-prone as the first. It is included here for the sake of 
> completeness. In the best case, the attacker could exploit a cross-site 
> scripting vulnerability on the target web server in order to construct a 
> login form (coming from the target server) containing a chosen session 
> ID. However, any attack that might manage to trick the user into logging 
> in through a malicious login form could just as well directed the user's 
> credentials to her own web server, which is generally a greater threat 
> than that of fixing the session.
>
> Session ID in a cookie
>
> Cookies are a predominant session ID transport mechanism, partly due to 
> their perceived security in comparison to URL arguments and hidden form 
> fields. Ironically, cookies provide the most convenient, covert, 
> effective and durable means of exploiting session fixation 
> vulnerabilities. What the attacker must do is install the trap session ID 
> cookie on the user's browser. She can choose one of three methods:
>
> A. use a client-side script that sets a cookie on the browser;
> B. use the HTML <META> tag with Set-Cookie attribute;
> C. use the Set-Cookie HTTP response header. 
>
> STEP 3: Session entrance
>
> After the user has logged in to the trap session but before he has logged 
> out, the attacker can enter the trap session and assume the user's 
> identity. In many systems, the attacker will be able to use the session 
> without the user raising suspicion. If the user doesn't log out of the 
> web server, the attacker has an opportunity to keep the session alive - 
> and thereby continue to assume the user's identity - for a long period of 
> time.
>
> Countermeasures
>
> First, we must make it clear that preventing session fixation attacks is 
> mainly the responsibility of the web application, and not the underlying 
> web server. The web server - which usually provides the session 
> management API to applications - should make sure that session IDs can't 
> be intercepted, predicted or brute-forced. But only the web application 
> can implement effective session fixation protection.
>
> Preventing logins to a chosen session
>
> There is one common denominator to all session fixation attacks and 
> scenarios: the user logs in to a session with an attacker-chosen ID, 
> instead of having been issued a newly generated session ID by the server. 
> Since there seems to be no compelling reason for web applications to 
> explicitly allow this to happen - and it indeed seems more like a side 
> effect of current implementations -, we propose forceful prevention of 
> logging into a chosen session. Web applications must ignore any session 
> ID provided by the user's browser at login and must always generate a new 
> session to which the user will log in if successfully authenticated.
>
> Preventing the attacker from obtaining a valid session ID
>
> A web application that is run on a "strict" system (one that only accepts 
> session IDs that it generates itself, and not arbitrary session IDs) 
> should only issue session IDs of newly generated sessions to users after 
> they have successfully authenticated - as opposed to issuing them along 
> with the login form. This means that an attacker who isn't a legitimate 
> user of the system will not be able to get a valid session ID and will 
> therefore be unable to perform a session fixation attack. 
>
> Restricting the session ID usage
>
> Most methods for mitigating the threat of stolen session IDs are also 
> applicable to session fixation. Some of them are listed below.
>
> * Bind the session ID to the browser's network address (as seen by the 
> server). 
>  
> * Bind the session ID to the user's SSL client certificate (this is a 
> very important and often overlooked issue in highly critical 
> applications: each server-side script must first check whether the 
> proposed session was actually established using the supplied 
> certificate).  
>
> * Make certain that session destruction, either from a logout or timeout, 
> must take place on the server (deleting the session). Deleting the 
> session cookie on the browser is not sufficient.  
>
> * Users must have an option to log out, thereby destroying not just their 
> current sessions, but also any of their previous sessions that may still 
> exist (in order to prevent the attacker from using an old session a user 
> forgot to log out from).  
>
> * Consider implementing absolute session timeouts to prevent attackers 
> from maintaining a trap session as well as maintaining an already entered 
> user's session for a long period of time. 
>
> Conclusion
>
> Session fixation is a fairly obscure but often quite severe 
> vulnerability, and therefore very likely to appear in web applications 
> written by developers not familiar with this exploit. Protecting against 
> session fixation is a non-trivial task, especially on "permissive" web 
> servers (those accepting arbitrary session IDs). In response to 
> significant interest in the developer community, we are currently 
> preparing detailed instructions on defending against session fixation on 
> different web server platforms.
>
> About the Author
>
> Mitja Kolsek has been active in information security for over 6 years, 
> reviewing a wide array of business-critical security products, computer 
> systems and protocols, successfully searching for security flaws and 
> effective ways for fixing them. As co-founder and CTO of ACROS Security 
> (www.acros.si), Mitja is passing his dedication to concise, in-depth and 
> exhaustive approach to information security onto other team members as 
> well as the customers they work for. 
>
> ----------------------------- Notice ----------------------------------
> This newsletter is a subscription-based publication of TISC, LLC. You 
> have received this newsletter because you attended The Internet 
> Security Conference in the past and/or subscribed to this publication. 
> If you receive this newsletter in error, please notify us by sending a 
> copy of this message to insight () tisc2003 com?subject=removeme. To 
> (re)subscribe, contact insight () tisc2003 com?subject=subscribe. 
> TISC LLC and affiliated companies are not responsible for errors or 
> omissions in this newsletter; author opinions expressed herein do not 
> necessarily reflect the views of TISC, LLC. For more information about 
> TISC, Insight, and our privacy policies, visit http://www.tisc2003.com.
> ***********************************************************************
> The Internet Security Conference 
> The World has Security Problems. We have answers.

--

Gary Gwin
http://www.cafesoft.com

*****************************************************************
*                                                               *
*   The Cafesoft Access Management System, Cams, is security    *
*   software that provides single sign-on authentication and    *
*   centralized access control for Apache, Tomcat, and custom   *
*   resources.                                                  *
*                                                               *
*****************************************************************