Where is JSESSIONID stored? (JavaEE)

问题:

I have two applications - A Java EE web application and a Java SE applet. I want to authenticate a user in the applet by means of a JSESSIONID (which is created by the web application).

So there is a problem - how to associate this JSESSIONID with a particular user?

How to check (on the web server application side) which user is represented by such JSESSIONID? In the applet I will be reading it from a cookie, and then I want to write a simple Servlet which will accept this JSESSIONID as a POST message. Thereafter I would like to write in the response nothing at all when the JSESSIONID is bad, and the user info if JSESSIONID is good (i.e. is representing someone).

Does anyone know how to do this?

回答1:

JSESSIONID is a low-level mechanism that you typically shouldn't care about. On the server side the servlet container transparently translates JSESSIONID to an HttpSession object available in the servlet. The session id is passed to the server transparently as well using Cookie header or URL rewriting.

So if you are clicking on a link or posting an ordinary form in a webpage, the browser automatically passes JSESSIONID cookie or attaches it to URL.

Your design has a major flaw: secure servlet containers should add HttpOnly attribute to JSESSIONID cookie (see: How do you configure HttpOnly cookies in tomcat / java webapps?) This is to prevent JavaScript from reading JSESSIONID cookie for security reasons - like hijacking user session. Your applet might not even see that cookie!

I don't know much about applets, but I would advice you to perform HTTP request via web browser somehow so the security identification (cookie) is handled automatically.

回答2:

The Java EE container will do most of the work for you. There are a couple of short-cuts you can take depending on with authentication method you use and the details of how the container behaves. I'll ignore those short-cuts for now. I am assuming that the user provides their information to the web application in some form - for example by logging in.

When the user logs in, create a session (if one doe snot already exist) and add their user name (and any other details you like) to the session as session attributes.

When a request comes in that already has a session, just retrieve the user details from the session. The container takes care of mapping the session ID in the request to the right session object and making that available to the request.

If the session ID is invalid, the container will not associate a session object to the request.

One final thing to watch out for is HttpOnly cookies. Containers should be using these by default for session IDs (to protect against XSS attacks). For the session ID to be available to the applet you'll need to disable the HttpOnly protection for the session cookies. This means that if you application has an XSS vulnerability it will be easy for an attacker to steal user session cookies.