4

In a web application based on propraietery MVC and authorization model, we have recently migrated to Spring MVC. As part of that move, we are also looking at moving away from a locally created GUID that is passed with each request to a cookie based Session ID.

On the face of it, it looks as if in our case, doing so will be a big disadvantage as the standard JSESSION/HttpSession seems to be the root of all security evils:

  1. Session Fixation (In existing code session is only created after succesful login, so we need never invalidate() a sessions.
  2. CSRF - Session is never passed as a cookie so this is never a risk (and god, it's a problematic one to handle since there is no real framework or generic solution out therem checked HDIV and CSRFGuard).
  3. Testing Useability - QA can easily have multiple users with multiple roles connecting to the same Server, not possible with JSESSION.
  4. In consistent HTTPSession creation and invalidation in various Containers (Weblogic, JBOSS and Websphere)
  5. Inconsistent JSession handling when moving between HTTP to HTTPS.

So, other than the obvious advantage of "being standard", Any clues as to why would I want to go the JSESSION route?

JAR.JAR.beans
  • 9,668
  • 4
  • 45
  • 57
  • I'm curious to know, what about HDIV and CSRFGuard you found to be inadequate for CSRF protection? – laz Jun 07 '11 at 17:27
  • HDIV support was is not sufficient. It looks like an intresting package, and I wish I could use it. But I had problem implementing it based on the documentation and when I needed help, there was no response. You can check the forums there to see the movment. – JAR.JAR.beans Jun 11 '11 at 08:37
  • CSRFGuard looks like a good solution, but it was just too ackward in the space of CSRF. I already had my proparierty session ID, I replaced it with JSESSION to see that I have CSRF issues, so now I could add a new package that will generate... a proparierty session ID.. I was better off (and that's what I did) left JSESSION out of my solution, it is simply not useble in some RIA solutions, as in my case. – JAR.JAR.beans Jun 11 '11 at 08:40

2 Answers2

1

Not really a categoric answer about why you should or should not use jsession, but stil some remarks regarding your concerns:

  1. Your application should not rely on the fact that a session exist or not. It should rely on the fact that the session is valid according to certain rules you put on it (user authenticated, roles assigned to this user, etc...)
  2. CSRF is not really a big deal as long as you take care to not use GET for sensible actions, and as you mention Spring MVC, it is quite easy to achieve with it.
  3. True, if you only rely on one browser. And as a side note, while manual testing remains a must for some situations, many use cases can benefit from automation, and thus reduce the impact of having to switch from a role to another.
  4. Never encounter a problem with that. But I tried to kept the content of the session as small as possible.
  5. And that's a good thing. It can prevent you from moving away from your secure connection without noticing it.

Now, whatever the option you'll choose, there will always be some drawbacks. Having a UUID in each request (and thus potentially in each GET URL) does not allow your users to use bookmarks easily. Nor to keep their session alive.

gizmo
  • 11,819
  • 6
  • 44
  • 61
  • Few comments on your remakrs (and thanks for it): 2) Not true, CSRF is far more dangerous than beleived and can easily be used in POST as well (and Spring MVC) 4)Websphere, for instance, will not create a session unless HttpSession.getSession is called, unlike the behavioru of weblogic. But overall, I do not hear any "Big No" for avoding Jsession, thanks. – JAR.JAR.beans Mar 04 '11 at 15:05
0

After much discussion analysis and testing, it seems that tleast in my case, a non RESTfull application, with a desktop like RIA UI, and extensive security considration, JSESSION is not the way to go (CSRF mainly) and a better option is a BODY based internally generated key. This does mean though, that the application will be forced to handle timeouts and session invalidation.

JAR.JAR.beans
  • 9,668
  • 4
  • 45
  • 57