Bug 45255 - support disable jsessionid from url against session fixation attacks
support disable jsessionid from url against session fixation attacks
Status: RESOLVED FIXED
Product: Tomcat 5
Classification: Unclassified
Component: Catalina
5.5.28
PC Windows XP
: P1 enhancement (vote)
: ---
Assigned To: Tomcat Developers Mailing List
http://en.wikipedia.org/wiki/Session_...
:
: 40222 (view as bug list)
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2008-06-23 01:33 UTC by quaff
Modified: 2010-08-25 15:01 UTC (History)
9 users (show)



Attachments
Patch to allow URL rewriting to be disabled (3.96 KB, patch)
2009-02-19 18:45 UTC, Dillon Sellars
Details | Diff
Updated patch (6.96 KB, patch)
2009-04-26 10:26 UTC, Dillon Sellars
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description quaff 2008-06-23 01:33:05 UTC
please see wikipedia
http://en.wikipedia.org/wiki/Session_fixation
Comment 1 Mark Thomas 2008-06-23 01:43:25 UTC
Please read SRV.7.1 of the servlet spec.

An option could be adding to disable URL-rewriting (noting that this would be non-spec compliant).

Requests for enahncements that are accompanied by patches tend to get looked at sooner that those without.
Comment 2 Rainer Jung 2008-06-23 01:58:29 UTC
Hi Mark,

Spec 7.1 seems to say:

- a compliant container may support URL encoded sessions ("may be used")
- if it does support them, it has to use the path parameter "jsessionid"

So if a site decides to only use cookies because of security, it could be an interesting option to allow not even accepting session IDs which were URL encoded.

What do you think?
Comment 3 Mark Thomas 2008-06-23 02:32:36 UTC
SRV.7.1.4 is the important bit for us. If we disable URL-rewriting we break the spec. That said, I am not against it as an option (probably at the context level) providing it defaults to off.
Comment 4 Rainer Jung 2008-06-23 02:40:39 UTC
Ahh, of course you are right. I'll see how easy an option is (I guess the incoming session path parameter and cookie is handled in the connector, and the context later doesn't know, where the id in the request came from ...).
Comment 5 Rainer Jung 2008-06-23 02:46:58 UTC
Sorry, again I wrote partial nonsense: there is a request.isRequestedSessionIdFromURL() in the servlet API. So it is easy for us to know, but also for the webapp. One could thus prevent session fixation via the jsessionid path parameter by a simple filter, that invalidates the session, if request.isRequestedSessionIdFromURL() is true.
Comment 6 Mark Thomas 2008-06-23 02:56:29 UTC
That would work. If we wanted to make this a Tomcat option the code around the context configuration option cookies is where I would start.
Comment 7 Dillon Sellars 2009-02-19 18:45:27 UTC
Created attachment 23284 [details]
Patch to allow URL rewriting to be disabled

Attaching a proposed patch for review.
Comment 8 Dillon Sellars 2009-03-23 07:34:47 UTC
It's worth mentioning that checking request.isRequestedSessionIdFromURL() won't stop session fixation attacks. The first request to Tomcat where a session is created will put the JSESSIONID in both the cookie and querystring. An attacker can shoulder-surf and read the JSESSIONID from the URL and craft their own JSESSIONID cookie.
Comment 9 Folke B. 2009-04-24 16:38:05 UTC
(In reply to comment #7)
> Created an attachment (id=23284) [details]
> Patch to allow URL rewriting to be disabled
> 
> Attaching a proposed patch for review.

We also need to make sure that "jsessionid" isn't accepted anymore if present.

Please take a look at CoyoteAdapter.parseSessionCookieId() and make the patch apply the same checks to parseSessionId() with context.getUrlRewriting().

Thanks!
Comment 10 Dillon Sellars 2009-04-26 10:26:29 UTC
Created attachment 23544 [details]
Updated patch

Good catch, patch updated. 

Added the check to CoyoteAdapter.parseSessionId() - had to move the mapping of the context up before parseSessionId() and had to move URI decoding before mapping the context. 

Patches without conflict with the httpOnly changes. 

Changed param in comment / interface from cookies to urlRewriting in Context & StandardContext.
Comment 11 Mark Thomas 2009-04-26 14:01:36 UTC
The Servlet 3.0 spec (ie Tomcat 7 / trunk) includes this as part of the spec. Look for javax.servlet.SessionTrackingMode

I think this will do everything you are looking for, although it does mean waiting for Tomcat 7.
Comment 12 Folke B. 2009-04-27 09:08:54 UTC
(In reply to comment #11)
> The Servlet 3.0 spec (ie Tomcat 7 / trunk) includes this as part of the spec.
> Look for javax.servlet.SessionTrackingMode
> 
> I think this will do everything you are looking for, although it does mean
> waiting for Tomcat 7.

Sadly, Tomcat 7 may not be an option for many of us for a long time. I had to fight really hard for the switch to Tomcat 6. Please reconsider applying this small patch to Tomcat 6 because session fixation is a real threat. 

Though it's reassuring to have Tomcat abide by the rules by default, it wouldn't hurt to give users more options, even spec breaking options, especially when it comes to security. I'd rather have Tomcat warn me that the webapp is deployed into a non-compliant context than putting my client's data at risk.
Comment 13 Dillon Sellars 2009-04-27 13:36:42 UTC
At least where I work this is on a security checklist - having this in Tomcat 6 will lead to more adoption. This is something that ops / admins will look for in SpringSource tc Server as it is already configurable in Jetty, Weblogic, Resin, Glassfish, and WebSphere. It's a case where it is better to break the spec (not by default) for security purposes. I'd love to see it in 6.0.19 if possible. Running patched makes one second guess everything - I'd like to be running the same binaries as everyone else.
Comment 14 Kalpesh Patel 2009-06-29 03:35:12 UTC
I think this option will be realy usefull to fight against session fixation problem. Looking forward to have this patched in tomcat 6.
Comment 15 Giampaolo Tomassoni 2009-08-31 06:10:36 UTC
I would urge to put Sellars' patch into the next Tomcat 6 version. It may not be the final weapon against session fixation (also a cookie-based attack seems possibile to me), but it is definitely good in fixing plenty of problems with search engines and ugly URLs...
Comment 16 Rejeev Divakaran 2009-09-23 09:47:24 UTC
I think we have mis-understood Session fixation. disabling URL re-write will not solve session fixation. 
Please refer to http://www.owasp.org/index.php/Session_Fixation 
and http://rejeev.blogspot.com/2009/09/session-fixation_08.html 
The correct solution for Session fixation is to create new Session cookie each time an authentication happens (discard old cookie and send new cookie to client after authentication).
Comment 17 Mark Thomas 2009-09-23 10:20:36 UTC
Actually, preventing the use of the session ID in the URL goes a long way to preventing session fixation as it blocks the most easily exploited attack vectors. There would remain an issue with cookies but that should be limited to 3rd party cookies which may not be an issue for many situations.

You are correct that changing the session ID on authentication will resolve all session fixation attacks. However, changing the session ID may also cause application breakage. It may also cause internal breakage for things like session replication. There would need to be some very careful testing.

Whilst each of these techniques can be achieved by web applications (some more easily than others), there is clearly some scope for adding options to Tomcat so the container handles this transparently.
Comment 18 Andre Schild 2009-11-17 11:48:35 UTC
A good document describing session fixation can be found here:

http://www.acros.si/papers/session_fixation.pdf

Just disabling the usage of jsessionid=.... in the URL does not solve the problem, it just closes one of many open doors.
Comment 19 jcran 2009-12-09 23:57:11 UTC
At the risk of sounding like a troll, this is a pretty major security issue. Why is it only now being dealt with?

True, it's not going prevent all session fixation, but as Mark Thomas mentioned, it goes a /long/ way, and makes it /much/ more difficult to pull off. You can no longer shoot a simple link to a user, and immediately have access to their session  

Regardless, it does prevent Session Hijacking  - http://en.wikipedia.org/wiki/Session_hijacking - (esp. in applications that don't expire the session on the server). 

Imagine you visit an application at a public PC, and a session ID is written to the URL. When that page is saved to the browser's cache, the URL is saved with the JSESSIONID parameter. A user could simply browse this cache, looking for valid session ids. 

Similarly, the session id can be cached in a proxy cache, or be sniffed along the path. 

Until this is fixed, i'm recommending the following:

Prevent SessionID from being written in the URL. There’s not an easy configuration option for this with Tomcat, unfortunately:
   http://forum.springsource.org/archive/index.php/t-27259.html

Ensure a new SessionID is set when the user successfully logs into the application. This will prevent an attack called Session Fixation: http://www.acros.si/papers/session_fixation.pdf 

Implement relatively quick expiring sessions on the server (30 mins or less)

Implement HTTPS w/ secure cookies (to prevent sidejacking - and issue that will persist regardless of session id's in the url)

More info here: 

http://blog.0x0e.org/post/277275694/tomcats-jsessionid-in-the-url
Comment 20 jcran 2009-12-09 23:59:01 UTC
i should be careful. it doesn't prevent all session hijacking. just certain use-cases. see comments above. 

jcran
Comment 21 Mark Thomas 2009-12-11 09:45:21 UTC
I have patched Tomcat 7 to change the session ID on authentication by default. The same patch has been proposed for 6.0.x and 5.5.x although the default may be not to change the session ID.

With this patch applied the situation is:
Tomcat 7
- Not vulnerable by default since session ID changes on authentication
- If this default is changed by the user (eg because the application can't handle a changing session ID) then the risks may be minimised by disabling session tracking via URL (a new feature in Servlet 3)

Tomcat 5 & 6
- Can be prevented by enabling changing the session ID on authentication (if there is insufficient support for this to be enabled by default)
- If the application can't handle a changing session ID then the risks may be minimised by writing a custom filter that checks request.isRequestedSessionIdFromURL() and responds accordingly (eg rejecting the request)

With these changes in place, although there will not be an option to disabled URL re-writing, I believe that there will be sufficient options to prevent session fixation which is, after all, the reason behind the request to be able to disable URL rewriting.
Comment 22 Mark Thomas 2009-12-19 17:05:23 UTC
The patch has been applied to 6.0.x and will be included in 6.0.21 onwards.
Comment 23 jcran 2009-12-30 07:36:31 UTC
Really pleased to see this integrated. Thank you Mark / Dillon. 

Just to be clear, we're waiting until Tomcat 7 to be able to remove the JSessionID from the url?
Comment 24 Mark Thomas 2009-12-30 07:50:25 UTC
(In reply to comment #23)
> Really pleased to see this integrated. Thank you Mark / Dillon. 
> 
> Just to be clear, we're waiting until Tomcat 7 to be able to remove the
> JSessionID from the url?

Yes, but Tomcat 5 & 6 will change the session ID on authentication which addresses the root cause of the session fixation. With that fixed whether or not the session ID is in the URL is moot.
Comment 25 jcran 2009-12-30 08:14:01 UTC
(In reply to comment #24)
> ...
> Yes, but Tomcat 5 & 6 will change the session ID on authentication which
> addresses the root cause of the session fixation. With that fixed whether or
> not the session ID is in the URL is moot.

So it appears that the session ID in the URL will be encrypted. I had to do some sniffing / digging myself - http://answers.google.com/answers/threadview/id/758002.html - but it's still bad practice, and introduces vulnerability. 

Consider the case of a proxy server, or of your own browser history. If you take a look, you'll see that jsessionid's are getting cached in the history, regardless of whether they were handed out after authentication or not. 

That aside, there's no reason that the browser couldn't cache the entire response, thus making this whole point moot -- it just doesn't out of the box. Removing the session ID from the URL would prevent browser history caching of a Session ID.
Comment 26 Mark Thomas 2009-12-30 08:37:02 UTC
(In reply to comment #25)
> So it appears that the session ID in the URL will be encrypted. I had to do
> some sniffing / digging myself -
> http://answers.google.com/answers/threadview/id/758002.html - but it's still
> bad practice, and introduces vulnerability. 

This is FUD. There is no vulnerability here.

> Consider the case of a proxy server, or of your own browser history. If you
> take a look, you'll see that jsessionid's are getting cached in the history,
> regardless of whether they were handed out after authentication or not. 
> 
> That aside, there's no reason that the browser couldn't cache the entire
> response, thus making this whole point moot -- it just doesn't out of the box.
> Removing the session ID from the URL would prevent browser history caching of a
> Session ID.

More FUD.

The situations you describe are not vulnerabilities. Since Bugzilla is neither a support forum nor a discussion forum, if you wish to continue this discussion further, please do so on the users list.
Comment 27 Mark Thomas 2010-03-03 23:12:24 UTC
The ability to change the session ID on authentication has been added to 5.5.x and will be included in 5.5.29 onwards.
Comment 28 Arvind Srinivasan 2010-06-04 08:51:33 UTC
Should changing the session id of an existing session object be treated the same as creating a new session i.e. should the session creation listeners be triggered?

http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/container/catalina/src/share/org/apache/catalina/session/ManagerBase.java?r1=903083&r2=918761 invokes setId() which in turn invokes the session creation listeners in tellNew().
Comment 29 Mark Thomas 2010-08-25 15:01:59 UTC
*** Bug 40222 has been marked as a duplicate of this bug. ***