Hi Jakob - I'm not sure that Shiro is retaining the JSESSIONID value. During logout, the session is invalidated and the JSESSIONID cookie is explicitly deleted. If you log out and redirect to another page, and that page requires session access, a new session (with a new JSESSIONID cookie) will be created.
This assumes you are using Shiro 'native' sessions and not the servlet container sessions. Shiro has no control over how the Servlet container manages session cookies - but if you use Shiro native sessions, obviously Shiro knows how to handle that situation. You of course have to log-out the user in order for Shiro to clear the cookie. If you don't (subject.logout), then the session id cookie will remain. If it remains long enough, it will be orphaned, and the next time the user comes to the site, the old cookie will be discovered, deleted and a new session/cookie will be created. Does this help? Do you have a scenario or sample that demonstrates this behavior? Again, if you're using the default servlet-container sessions, Shiro has no control over how they operate. Regards, Les On Tue, Apr 20, 2010 at 3:54 AM, Jakob Külzer <[email protected]> wrote: > Hey everybody, > > I'm currently working on a Grails app that utilizes the Shiro plugin. I'm > not really sure if the problem is in Shiro or the Grails plugin -- but after > poking in the plugins' source code I think its an issue with Shiro. > > The problem I'm having is that Shiro retains JSESSIONID's over logins > rendering it vulnerable to session fixation attacks > (http://www.owasp.org/index.php/Session_Fixation). The app I'm working on > has to meet very high security standards and this issue has been flagged. So > far I have been unable to work around it. > > Is there a way to get Shiro to restart the session and therefor prevent > session fixation attacks? Or is there another way to prevent them that I am > not aware of? > > -- > Cheers, > Jakob >
