Security conscious developers, world over, look to the OWASP Top Ten as their do’s and dont’s guide. The importance of this list, to the application development and security communities, cannot be exaggerated. Have a look at these impressive statistics from one of Jeff Williams’ recent presentations:

Thus, a Top Ten vulnerability should be one that occurs most commonly and has a high potential impact; something that developers should be made aware of. Based on this premise, session fixation should bull doze into the OWASP Top Ten.  Over 90% of all Java web applications that we have reviewed in the last couple of years have been susceptible to this attack. Combined with a little phishing, this attack can result in users’ accounts on vulnerable websites being hijacked. Let’s take a little detour and understand how this attack most often works.

• The attacker requests the home page of the vulnerable website
• In response the attacker’s browser is provided a jsessionid. Note: No authentication has occurred
• The attacker extracts the jsessionid from the response and constructs a legitimate URL with the jsessionid in it as follows:

https://www.vulnerablesite.com/login.jsp;jsessionid=<insert the extracted token here>

• The attacker then emails this link to a potential victim – a legitimate user of the website
• The victim does not find anything “phishy” with the URL. It actually points to the SSL website; no phony subdomains, suspicious IP addresses, illegible URL encoding, etc.
• The user clicks the link and is presented the login page. What the user doesn’t know is that his or her session is associated to the jsessionid in the clicked URL.
• The jsessionid continues to be associated with the user’s session post-login too.
• Now, the attacker can browse to any restricted page of the website by merely appending the jsessionid in question to the request. The application believes that the attacker is the victim and will readily provide the former access to the victim’s profile- think bank account.

Due to the default behavior of most Java application servers, web applications using the jsessionid for authorization, are often rendered vulnerable. Don’t get me wrong – I am not recommending against the use of jsessionid as an authorization token. I am only calling for the issue to be brought to the fore front by the foremost application security community – OWASP. Especially because it has an easy fix; developers should invalidate the session after critical events like login and re-issue a session ID.

session.invalidate();
session=request.getSession(true);

Also, disable URL re-writing in web.xml.

Some may argue that session management is  included in “A7 – Broken Authentication and Session Management” of the OWASP Top Ten. Yes, it is. However, just like cross site scripting and injection flaws got their own spots and were not clubbed under input validation, session fixation too demands the spotlight.    

-Rohyt