Results 1 to 2 of 2
  1. #1
    Puzzled is offline Member
    Join Date
    Mar 2016
    Rep Power

    Default Removing everything from the session map instead of invalidating the session???


    I am currently working on a JSF 1.x application whose lead developer left the company a while ago and I am somewhat puzzled as to something he did in it...

    I was told to address a few security related issues related to the handling of the session (once you log on you get a new session and things like that).

    I still had a lingering problem related to session handling, when I logged off I would keep the same JSESSIONID as when I was logged on.

    It turns out the that the lead developer was not invalidating the session with a session.invalidate() but instead was going through every key of the session map and removing them.

    I was getting the same JSESSIONID after I had logged off because I was essentially still in the same session.

    Is this a legit way to log off? To me it doesn't sound like it is but the guy was supposed to be some sort of Java guru so I don't know what to think anymore...

    Any ideas?

    Thank you!

    Last edited by Puzzled; 03-14-2016 at 07:21 PM.

  2. #2
    SurfMan's Avatar
    SurfMan is offline Godlike
    Join Date
    Nov 2012
    The Netherlands
    Rep Power

    Default Re: Removing everything from the session map instead of invalidating the session???

    As far as I know, invalidating the session after logging out (and after logging in too), is the way to go. I have no idea why you would empty the current session and keep it going. This means that anyone using your hijacked session can still continue to do so. Invalidating the session prevents reuse of the session. Delete the code and replace it with session.invalidate(). If there REALLY was a good reason for it, he should have documented it.

    Remember that in the Land of the Blind, the One-eye is King. :)

    Edit: a nice reference is the OWASP recommendation: (

    Renew the Session ID After Any Privilege Level Change

    The session ID must be renewed or regenerated by the web application after any privilege level change within the associated user session. The most common scenario where the session ID regeneration is mandatory is during the authentication process, as the privilege level of the user changes from the unauthenticated (or anonymous) state to the authenticated state. Other common scenarios must also be considered, such as password changes, permission changes or switching from a regular user role to an administrator role within the web application. For all these web application critical pages, previous session IDs have to be ignored, a new session ID must be assigned to every new request received for the critical resource, and the old or previous session ID must be destroyed.

    The most common web development frameworks provide session functions and methods to renew the session ID, such as “request.getSession(true) & HttpSession.invalidate()” (J2EE), “Session.Abandon() & Response.Cookies.Add(new…)“ (ASP .NET), or “session_start() & session_regenerate_id(true)” (PHP).

    The session ID regeneration is mandatory to prevent session fixation attacks [3], where an attacker sets the session ID on the victims user web browser instead of gathering the victims session ID, as in most of the other session-based attacks, and independently of using HTTP or HTTPS. This protection mitigates the impact of other web-based vulnerabilities that can also be used to launch session fixation attacks, such as HTTP response splitting or XSS [4].

    A complementary recommendation is to use a different session ID or token name (or set of session IDs) pre and post authentication, so that the web application can keep track of anonymous users and authenticated users without the risk of exposing or binding the user session between both states.
    Last edited by SurfMan; 03-15-2016 at 03:22 PM.
    "It's not fixed until you stop calling the problem weird and you understand what was wrong." - gimbal2™ © 2013

Similar Threads

  1. Replies: 4
    Last Post: 09-09-2014, 06:03 PM
  2. session.close() doesnt end database session.
    By ali_sakar in forum Hibernate
    Replies: 10
    Last Post: 12-12-2012, 11:53 AM
  3. Replies: 1
    Last Post: 04-22-2009, 12:20 AM
  4. Replies: 2
    Last Post: 12-23-2008, 07:35 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts