Question

During some debugging of our WebLogic application, I’ve noticed that the JSESSIONID doesn’t change after the user logs out.

I’m trying to understand if this is something I need to be concerned with.

This application is one of two applications running within a WebLogic instance, and I notice that they both share the same JSESSIONID.

This question makes reference to the following:

SRV.7.3 Session Scope

HttpSession objects must be scoped at the application (or servlet
context) level. The underlying mechanism, such as the cookie used to
establish the session, can be the same for different contexts, but the
object referenced, including the attributes in that object, must never
be shared between contexts by the container.

This suggests that ultimately it’s up to WegLogic to choose how to manage these JSESSIONID values, and I should not try to interpret meaning from the change in value (or lack thereof).

Additionally, I’ve wired up an HttpSessionListener on the application, and I see the sessionDestroyed method get invoked.

Given these two elements, it seems safe to me that the JSESSIONID is not changing. However, this is different behaviour from what I’m used to, so would like to verify my assumptions.

Is it a security concern that the JSESSIONID doesn’t change?

Answer 1

No, it shouldn’t be a huge security concern, since all the data that was actually associated with that session is discarded. The JSESSIONID is just a key to that (now nonexistent) data.

However, if you want the JSESSIONID to change on each logout/login, you could just implement your logout functionality such that it explicitly deletes the JSESSIONID cookie when the user logs out. Then the server will allocate them a brand new session/id on their next request.

Of course, as noted in the documentation, if you have multiple contexts that all happen to be relying on the single JSESSIONID cookie, then deleting it from one will essentially delete it from all, effectively logging the user out of every context on your server. Although in practice, it’s not hugely common to have multiple user-facing contexts, each with its own login/session state.