please see wikipedia http://en.wikipedia.org/wiki/Session_fixation
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.
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?
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.
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 ...).
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.
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.
Created attachment 23284 [details] Patch to allow URL rewriting to be disabled Attaching a proposed patch for review.
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.
(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!
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.
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.
(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.
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.
I think this option will be realy usefull to fight against session fixation problem. Looking forward to have this patched in tomcat 6.
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...
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).
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.
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.
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
i should be careful. it doesn't prevent all session hijacking. just certain use-cases. see comments above. jcran
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.
The patch has been applied to 6.0.x and will be included in 6.0.21 onwards.
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?
(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.
(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.
(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.
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.
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().
*** Bug 40222 has been marked as a duplicate of this bug. ***