Hey Les, See my comments below:
On Wed, May 19, 2010 at 2:41 PM, Les Hazlewood <[email protected]>wrote: This won't work unless the hacker specifies a session ID for a session > that is *currently active*. If the corresponding session is > stopped/expired or doesn't exist, a new session will be created in all > cases, and a new session ID cookie will be set. > I agree on that. And usually this should not happen, the servlet container should not accept session IDs in the URL and computers should be safe. The scenario I have in mind is a typical session fixation attack where one of the above assumptions (clients browser is secure and/or servlet container accepts JSESSIONID as part of the URL) is not met. It is a real concern to my client and I would like to provide a solution to this. > All web frameworks rely on you to keep your cookies secure if you feel > they constitute sensitive information - e.g. use SSL or turn sessions > off in JSP pages that shouldn't rely on sessions. > Good thoughts. SSL is in place, but I didn't think of turning off sessions on non session relevant pages. > Not at the moment - that would be a new feature request - please add > it to Jira if you think it would be useful. > I'll add an according feature request; I'm convinced this would add another layer of security for applications using Shiro. > > Sorry for the delay in responding to this email thread - we've been > very busy wrapping up the 1.0 release. > No worries. Keep up the good work! :) -- Cheers, Jakob
