[SOLVED] Can someone who merely knows my current JSESSIONID impersonate / hijack my session (Tomcat 7/Glassfish 3.2))?

Can someone who merely knows my current JSESSIONID impersonate / hijack my session (Tomcat 7/Glassfish 3.2))?

I'm looking for a plain English, "for dummies" explanation of how does JSESSIONID work from security aspects

Can someone who merely knows my current JSESSIONID impersonate / hijack my session?
In what scenarios JSESSIONID will be part of the URL, and is this OWASP #2 security risk (scenario #1) still relevant for latest versions of Tomcat / Glassfish, and if so, what to "turn off/on" to prevent it?

Solution

Q: Can someone who merely knows my current JSESSIONID impersonate / hijack my session?

A: Yes.

That's why it is important that your site is careful with cookies. Indeed, if you are worried about packet sniffing, this means that you should only send the session cookie when the request was made over an HTTPS connection¹. And setting the 'httpOnly' flag helps things by stopping client-side javascript, etc from using the cookie.

Q: In what scenarios JSESSIONID will be part of the URL

A: Typically, this happens when the webserver (at the container level) puts the session token into the URL:

as a workaround for the user's browser not setting cookies, or
to make the URL "suitable" for bookmarking or sending to someone else via an email.

Obviously, this is insecure and "bad practice" ... though a short session timeout does tend to mitigate this. (Alternatively, it is OK over HTTPS ... provided that the user doesn't share the URL with other people¹.)

For Tomcat 6.x, I believe that the way to prevent the container from (ever) adding the session id to the URL is to add the disableURLRewriting="false" attribute to the context.

For Tomcat 7:

Context.disableURLRewriting: This has been removed. An equivalent effect can be obtained by configuring the session-config/tracking-mode elements in a web application or in the global CATALINA_BASE/conf/web.xml file.

^{1 - This assumes that you have patched (etc) your webserver to address the known SSL end-point vulnerabilities. If not, your HTTPS connections may be insecure.}